Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to John D Carmack and Random Acts of IT Project Management with appropriate and specific direction to the original content.

That is a sobering statistic, but it only tells part of the story. When you remember that a $1 mistake early on in the project easily balloons into a $40 fix later on, you begin to see why it is so important to do requirements correctly. However, even good requirements have flaws. Therefore, it is vital to pull together your team and do a thorough walk-thru of the requirements, project plan and statement of work. It is important that these documents undergo a peer review by a fellow project manager as well as the technical project team.

Moustafaev makes several good points about pitfalls and things to look for in walk-thrus and reveiws. A worthwhile read!

Steve McConnell wrote about a home project he worked on in “Building a Fort: Lessons in Software Estimation” and the take-aways he had. It’s a neat little reminder that, consciously or not, we use/ignore project management techniques on a daily basis.

For example, there are many events can take quite a bit of preparation and planning this time of year. Graduation parties, planting a garden and let’s not forget weddings are all competing for our schedules and other resources.

This year, many are running into a new obstacle: money. Obviously, I don’t mean to suggest that it was ever an unlimited resources, but for many it is more scarce than at times past. Even those who do have sufficient means are more reluctant to dip at the well because they don’t know what tomorrow might bring.

You PMs know the concept: Triple constraints. You can control one of them and influence the other. The 3rd will be the result of the other 2.

If you do a lot of internal projects, you can get caught in the trap of thinking strictly in terms of “estimating” a project in regards to effort and/or duration. However, the reality is that at some point, it boils down to the bottom line. “Time is money” goes the expression, and a project may have little effort required, but the outsourcing or off-the-shelf aspect of it drives up the cost.

Let’s face it that companies as well as individuals are very interested in the bottom line. The controlling factor in your project is likely to be the budget.

That’s not always a bad thing. As I go around the house, I keep thinking, “Do I really need mulch here? If so, how much do I really need?” Surprisingly, I’ve run into 2 other homeowners with the same exact thoughts recently. We learn to tighten our belts and become more efficient homeowners.

Companies can learn to become more efficient as well. Some will not. For some, it may be too little, too late. Some will try to ride it our, but they will either make no changes or make the wrong changes. Others will learn to adapt. They will learn better ways to get things done.

There used to be a time when if a person ran out of money, they simply didn’t spend any more. Sure, you had your occasional exception that stupidly borrowed from the local loan shark, but most learned to live on less. They had to. It was called living within their means.

American credit had gotten way out of hand. We thought we could borrow utopia.

What I am saying is that we don’t have to continue to be that way. We can again learn to live within our means. We can learn to do more with less. We can work smarter instead of harder. These may sound like antiquated clichés, but they are sayings that came with the wisdom of experience of another generation who faced their needs head-on.

Meanwhile, I am going to have to go to the store and get a couple of items. One of them will not be mulch, I guess. I will have to control the one constraint (cost) better than scope or time (duration) for now.

If you don’t know where you are going, then you won’t know when you arrive. It really is a simple concept, but it seems to go over the heads of many executives. Unfortunately, it seems to go over the heads of some IT folks as well. When that executive wants something and wants it now, it is hard to push back sometimes. However, “something” is not a scope statement!

If I am dying of thirst, and I ask for a drink, then should I be dissatisfied when I get a cup of coffee instead of water? Now, I love a good cup of coffee as much as the next coffee addict, but I also know it isn’t going to cure my thirst. No, I should have been more specific. The person giving me the drink should’ve asked questions. Both failed to ask questions, and the task was not a success.

What makes a successful project? Isn’t it one that delivers the goods? If you don’t know what the goods are, how do you know when you succeed? You don’t. How do you know when you fail? When you have angry people making demands of you, which is almost a surety if you don’t live up to their expectations. That is almost a surety when the scope is not properly defined.

Ask the questions on any project:

What is success?

How do you measure success?

When are you done?

How do you measure done?

What is the minimum required?

What is the maximum timeframe?

Can the minimum required reasonably be planned, constructed, tested, reworked and retested in the maximum timeframe?

Will subject matter experts (SMEs) be available throughout the timeframe, or will you have to rely upon less experienced workers?a. Who is indispensible to the project’s success? When will they most be needed and can you be guaranteed their availability during critical times?

b. If less experienced people will be used, then is it reasonable that you can still do the minimum within the maximum timeframe?

Are there any stakeholders who do not buy-in on the changes?

Do you have executive support (real, not lip service)?

If any of the above are a concern, and if you cannot come up with a reasonable workaround or mitigation action for it, then it needs to be identified as a risk factor. The likelihood of the risk occurring must be widely published. The project sponsor must be engaged with the risk.

Remember that an unmeasurable business goal is no goal at all. Don’t start out with a hardware or software change as the goal. No, hardware and software changes may be functional requirements that support the business goal, but they are not in themselves the goal(s). “Change web interface to make customers happy” is not realistic or measurable. “Increase online sales by 5% by providing customers online discount codes” is a lot better. Now you have a business goal, you can start asking the question of where do the discount codes come from, how much the discounts are for and how and when they will be input into the system.

If you started with the interface, then the goal becomes short-sighted. You may not involve anyone in sales. You likely would not realize that you needed their involvement until late in the project. They may be only vaguely aware of your project, and they will likely have made assumptions about how it would work. The end result would likely be that no customer would receive any discount codes, so sales would remain flat in spite of any work being done.

Even worse, if the project sponsor cannot tell you definitively when a project is done and a success, then your project will have constantly shifting requirements, priorities and timelines. Force the measurements upfront. This will force any disagreements among stakeholders to be uncovered at the beginning and not at the end. This will differentiate between a success or a failure in objective terms.

Measurable goals help to define original scope. One requirements are mapped to the goals, and as long as the requirements themselves are measurable, then original scope is established. If there is no way to measure it, then the enduser/sponsor will want additional items put in without effective controls.