Blog: Dan E. Linstedt

« New skills required for BI and Data Presentation going forward | Main | New Skills Required - Interactive BI »

Part 5: Secrets of the Masters

As this series progresses, I've received some wonderful comments, thank-you to all who are replying. In this entry we'll talk about some of the additional skills that are helpful in managing and developing successful projects. We've touched on a few already, but I'm not convinced we gave enough credit to these items. Many people argue with standards, claiming they are over-burdening their development - claiming they can't get their job done with them, claiming they are too verbose or have too many pieces to work effectively. They revert to RAD, JAD, and extreme methodologies...

Why don't I mention Agile?
Because Agile can be blended appropriately with standards to make a huge difference. My friend Kent Graziano teaches how Agile methods combined with the appropriate data modeling and other practices can really make a positive impact on a team and their performance.

I personally like Agile, but obviously with a few twists.

Skill sets that I recommend people to have on projects (both big and small) are as follows:
* Agile Methodology
* SEI/CMMI Level 3 from Carnegie Mellon U. (at a minimum, level 5 if you can get it)
* PMP Certification from the PMI
* CoBIT from ISACA
* Knowledge of ITIL -
* Six Sigma
* Lean Initiatives (from MIT)
* Function Points - Link 1, and Link 2

You might say, GEE WHIZ How am I ever going to know all that?
Well, if you know what these things are, and can find people who are experts in specific areas, then your project will be better off. I don't claim to know all of each one of these, I only just have scratched the surface on each one enough to understand how to use certain tools within each of them to achieve my project goals.

I use a blended approach, the final touch is applying the Agile principles to all the knowledge to scope the project down and get it done. Remember, I'm not JUST talking about big projects here, I'm also talking about small projects. Small projects and small organizations typically are the worst offenders, often setting a precedent that quickly breaks when the corporation gets in to rapid growth mode.

Each of these base level knowledge areas (if you can call them that) have valuable information to take away. The methodology that you build should be put in to a cell - like grid. Take for instance the Zachman Framework, pick one or two cells within to implement, then expand it out and build a Linstedt Grid (just kidding), build a simple grid underneath the single Zachman cell, and figure out where each of these types of concepts apply.

I for one believe that at least one piece of each of these concepts can be applied effectively to create the optimal EDW/BI project methodology. Something light-weight enough to be used effectively (and not sit in a corner and gather dust), yet something practical.

The key is:
* ensure that all components chosen are practical
* ensure that the components are TEMPLATE driven, so that the PM AND the team only have to grab ONE template (don't give them more than one), and fill it in - and voila, they are compliant
* ensure that the templates don't require tomes of documentation to understand. In other words, fill the templates in with pre-cursory language that explains WHAT is in each section and WHY it is there.
* ensure that there is a SINGLE risk document in the binder that explains the RISK of using only one component, and not another.. In other words - when the customer demands that processes be short-cutted, and standards be broken, then be able to explain the risk of doing so - then have them sign an SLA that states they've been made aware of the risk.
* force yourself to learn, and follow the standards/cell based methodology you just built. If you don't follow it, no-one-will!

It's not SEI/CMMI Level 5 by itself that could help you be successful, nor is it knowing and understanding what documents are available in the ITIL, it's being able to leverage the right document and process at the right time where it makes sense within the project that really drives the point home. Believe me, I've been through this more than once - I've shot myself in the foot by breaking my own recommendations, but we've been able to recover from the errors by reverting to the standards.

Also keep in mind the following idea: If you were a ship captain, and you needed to go from NY port to Egypt to pick up spices, you probably would first: pick an acceptable route according to international trade law, then you would map the route out so you knew what all the coordinates are, as the trip neared, you probably would look at the reported weather patterns and check for re-routing instructions.

This would be a constant (agile) process of adjustment DURING sailing, as weather is unpredictable. If your ship got off-course, you'd want to put it back on-course or risk: loosing your captains license, loosing your ship to rocks on some coast, or hitting a sand-bar, running aground, loosing your cargo (if it's food, it might expire). Now in these days of GPS it's quite a bit easier, especially since it's integrated with the NAV systems, but that doesn't justify the Captain breaking international shipping regulations....

Ok, you get the point. A process, which has standards and rules to follow - can be accomplished successfully with a high degree of accuracy - has a little bit of real-time leeway to accommodate shifting weather patterns, and includes some uncertainty (like monster waves which take out entire ships). Also keep in mind that to turn these huge ships can take a tug boat (or several) within the harbor, or can take a day or two out at sea.

Just like a project, when it's off course or the standards have been broken, can take a "smoke-jumping team of experts" or can take several weeks to put back on track. It can be done, it just takes time.

Now, put it in perspective. Am I saying that even projects that are spec'd to take 3 weeks can use these principles? Yes, I am. Am I saying that they require ALL the documentation that a 6 month project requires? No I am not, this is where re-using the "templatized" project methodology components comes in to play. This is where Agile takes over the plans and implementation status.

Finally never forget scope. Always apply scope to the project to make it work properly. As far as the 30,000 page tomes that SEI/CMMI offer - strip them down, apply the components to your project templates that are necessary (I've mentioned a few in this series already like versioning, and SLA's etc...) What you will find is this: building an EDW/BI solution is more like building software than you think.... there are hundreds of thousands of parallels between the two worlds.

Next time, we'll dive in to some of the components from each of these that I'd suggest you start with. Anyone care to comment on pieces they've used successfully or pieces that have been applied and resulted in a negative impact on the project?

Thanks,
Daniel Linstedt
DanL@DanLinstedt.com

Share: