Common Pitfalls of Project Management | Part 1 - Shaky Requirements
Today, we start a series in which we will uncover some of the common pitfalls that can completely tank a project. Effective project management is a key asset of any organization, but especially for small businesses. When time, money, and resources are limited, it becomes even more critical that every project initiative is managed prudently and yields the expected return on investment. There should be a shared understanding of the objectives, measures of success, and the steps required to achieve that success.
From personal experience, one of the many things that plagues projects are vague or unclear requirements. Requirements gathering is typically one of the first activities completed at the onset of a new project. Executive sponsors, business users, project leadership, and technical staff get together to discuss and describe the future state. A project manager or other designated third party will facilitate these discussions and capture each specific use or function of the future state.
Issues come into play when these requirements are not described in detail. Take a look at the statements below. There's a marked difference. One is very specific and quantifiable; the other leaves much to interpretation.
"The system should perform well."
"The system should process 98% of all orders with no issue over a 24-hour period."
Vague or unclear requirements blaze the trail to project failure, primarily because there isn't a clear end goal. The team lacks clarity of the expectation and the stakeholders have no grounds to enforce accountability. Nobody wins. Time and money are wasted.
Here are a few tips to aid in securing great business requirements:
If it's not documented, it didn't happen. Period. Nothing's worse than trying to remind your project team of a conversation that took place 6 months prior in an effort to reiterate expectations (or worse - cover your butt). Document (and publish) everything.
During sessions, the question "Why?" should be asked ad nauseam. Reason being, it will help to uncover the true desired outcome at a very granular level. Practicing this habit will ensure a crystal level of clarity amongst all parties involved.
Where possible, ask for specific measurables that will determine the success of the future state. Ideally, success should be expressed in terms of monetary cost, value, time, effort, or some combination of them.
Play to a broad audience.
Be sure that you have a clear idea of who your stakeholder is. Once you do, engage them throughout the entire requirements gathering process. It can be tempting to assume that one person speaks for many. However, this is rarely the case. Tunnel vision is an epidemic that runs rampant in boardrooms. With that said, be inclusive in your requirements gathering conversations to be certain that you've gotten a cross-functional perspective of the desired state (and cross-functional buy-in).