This is a military principle that can be altered to reflect our systems once they are touched by the actual users. Sure, you followed the requirements but it just doesn’t seem like it works the way the business users expected once you went into production. Why does this happen? Here are just 4 of the most common reasons I’ve encountered.
1. User involvement was limited (at times or all the time).
2. Scope change/creep.
3. Ran out of time or money.
4. Vision was different on all sides.
A book can be written for each one of the above reasons (and probably has). The truth is, it is probably a combination of them all. When I talk to the business community, either those in the trenches or executives, I get this common response to a rollout system: “It’s not what I expected.”
Before this ruffles your feathers…think about it. Many technologists tend to get right to the details that they forget the overall intent of the project. They work with knowledgeworkers that understand their process in great details. Getting caught up in the develoment process, it is easy to forget the business why this is needed. What was the business objectives? What was the executives intent for this system?
The core of the idea for any system should be simple and to the point. It should be posted on every document and in every person’s cube that is involved in the development. I’m not talking mission statement. (Can you recite your company mission statement?)
I’m talking about the simple core of the projects purpose stripped down to its most critical essence. Unless you understand the core business issue, all participants will have a different ‘vision’ of what needs to be done and how it should look and feel. Once everyone understand the core, all decisions can be made quickly to support it. All designs can be made flexible enough to change with the growing scope creep or need for answers if it satisfies the basic core. Plans can be adjusted and money can change…if you at least support the core.
This idea on finding the core is from Made To Stick by Chip Heath & Dan Heath. It focuses on the corporate message but it can be extended to defining the essence of any project. It is hard to define and must be done so jointly by the business community (approved by executives) and IT.
Helping all size businesses find growth opportunities and demolish internal roadblocks to success.
Contact me to discuss how I can add real value to your bottom line. 
Sign up to receive the
Subscribe to the SBDi Tips Blog feed
July 21, 2008 at 11:14 am |
Mainly what you’re saying is that Agile Project Management is the solution where the client is much more involved during the project, this will dramatically decrease all of the above 4 risks.
July 21, 2008 at 11:35 am |
Many different management processes would decrease the risks. Following one management process works only with adjustments for the business community. For example, many, including Agile do require a significant amount of business user involvement. How many corporations will allow their top performers (sales, marketing, traders, executives, etc.) to participate all that time? Therefore, the checkpoints must include validation from these top performers. They will probably not be involved during the requirements phase or testing phase to the same degree as other Agile team participants.
Technical skills and process are important. My past interviews of key executives have found that having these top skills is only 40% of the success rate. The remaining 60% is tied to the ability of the business-interfaced IT staff to relate on an personal level with the business community. Many projects succeed despite the technology and process skills. They succeeded because of the business/IT relationship.
July 21, 2008 at 2:34 pm |
I definitely second you on the last sentence…