“Validate Critical Data”. I don’t remember what wise mentor I learned this from but it is one of those sayings that always goes through my head when I’m jumping into a new project. After many years it continues to be an important part of my project management success (when it is done right) and an unfortunate contributor to my project failures when it is neglected. Below are some keys to correctly validating critical data.
The word critical is not excess fluff in this phrase. You shouldn’t try to validate all information – just the information that has been handed to you that affects your project approach. Usually, it involves getting the right information about the project deliverables, scope, schedule and budget.
Often a project manager will inherit much of their project information. This second-hand information is highly suspect (remember the old children’s game where the story changes a little bit each time it is retold, until it is far from the truth). Information you inherit is always worthy of validating. Even when the information was correct initially as time passes the project environment or facts change. An added benefit of this practice of validation is to cause the sponsor to think a bit deeper about the issues than they did initially, and have the opportunity to change their answers.
I’ve had initiation meetings where, when asked to validate the project schedule, stakeholders admit they are not really ready to do the project yet because it is dependent upon other projects that have been delayed. The process of having a friendly discussion involving the validation of all the critical data is usually quite productive and valuable. It can feel awkward the first time you do it. You may get push back – “Don’t you already know the information?”, “Shouldn’t we be beyond this point by now?”, “Don’t you trust the people who gave you the project description?” But, later as the people you work with start to see that it is just a normal part of your process, the benefits of validation is appreciated. The meeting usually ends with “I’m glad we talked about that because I think it’s going to be a better project now that we changed a few of those decisions.”
Some critical data comes from our project stakeholders. Other critical data may come from us, and our assumptions that we have made about the project environment, about resources, processes, or technology. Putting the project assumptions into writing, and getting input from others on the assumptions, is another way to validate critical data. If our assumptions are incorrect, the plan needs to be changed as soon as possible.
So Validate Critical Data – The cost of implementing these changes early in the project is always less than making changes later.
Any fun or scary project stories to share where the validation of critical data either saved you or on the flipside lack of it came back to bite?