Poor requirements can triple the length of the project
Requirements are the lifeblood of the project. Period.
And bad requirements or missing requirements can triple the length of the project. Worse, they can kill a project altogether due to time or budget (or both) issues.
I just had a simple home project for my wife go south because I failed to get the requirements fully defined before starting. I thought I had everything right, but I made some assumptions without asking certain questions. Keep in mind she is my very organized wife who hates it when I ask too many questions before starting a project for her. But our project customers have a potential to be problematic, stubborn, demanding or even uncooperative, right?
Next project today I got detailed requirements and then clarified and asked a couple of questions. We were definitely on the same page. When the project was over an hour later – complete to the original specs (I thought, anyway) and I asked if this looked ok and she said “oh heck no.” This was an example of some customers who just can’t be pleased or impressed. You may have to cut them loose if this keeps happening, but in my specific case with my wife, of course, that isn’t going to happen… you get the picture.
So, what can we do to ensure this doesn’t happen / and to keep my wife from getting mad at me on my next home project? We can focus on these 4 things…
Schedule enough planning time.
One of the biggest reasons there are disconnects between what the customer wants, the requirements that get documented, and the solution your team builds is lack of enough planning time. Requirements are so critical – you really can’t spend too much time on them as long as it is reasonable for the project. But cutting corners on the requirements definition phase is a definite no-no. There is no specific yardstick on how long to spend planning and documenting requirements. I wish I could give you an exact formula and if I could I would probably be a millionaire. Initially, for a good-sized tech project that is going to last 6 months or more, I would put at least 2-3 weeks into the schedule with 3-4 dedicated meetings and several assigned subtasks. Understand that the window for documenting requirements may expand or contract – it will be hard to predict but you must document detailed requirements thoroughly and as accurately as possible. Period.
Ask more questions even if it may seem like too many.
The bottom line is this – we need to avoid bad requirements and mis-understood requirements at almost all costs. Extend the requirements definition phase out if necessary – even if it injures the project budget and timeline early on. That is far better than extremely costly rework later in the project that might also serve to triple the length of the project as suggested by this article’s title. Take more time to analyze, define and document requirements. Ask more questions – lots of questions – of the customer project sponsor, the subject matter experts (SMEs), the ultimate end users – anyone and everyone on the customer side that knows what they want and need from the solution. Complete requirements that are complex and detailed set the stage for successful user acceptance testing (UAT) as well as a well-designed end solution that will meet the users’ needs and bring a successful conclusion to the project engagement.
Repeat the requirements individually as they are documented.
This may seem either obvious or overly mundane – depending on the individual or personality type. And you can argue till your out of breath against it but if it saves even a few hours of re-work by 2 or 3 project team members that could be $10,000 of project budget saved just be clarifying a requirement out loud. It goes along with my stance of following up after every meeting with notes from the meeting to make sure everyone is on the same page. We all have the potential to hear things and interpret things differently and we all go into each communication incident with some pre-conceived notions and are therefore bound to come out the other side with some varying understandings. Repeat requirements – get common understanding. It’s logical… common sense. Most PM best practices are that logical. It’s not rocket science.
Review the full set of requirements before beginning any project work or next phase.
Once all the requirements for the effort are detailed and complete, the business analyst should schedule a 3-5-hour session (longer, if necessary – depends on the complexity of the project and the size of the requirements document you’ve assembled) to review and discuss the full set of connected requirements. Do these now make sense and fit together right to form the intended solution? I do this and have never regretted it. There has never been a project where at least five or ten key requirements weren’t missing some detail or omitted completely. On multi-million-dollar projects that may translate into a savings of $100,000 or more of re-work and lost schedule fixing what was wrong or missing. Again, this session is just good common sense… good communication and good management. Planning and documenting is critical, so is follow-up to ensure common understanding and completeness.
Summary / call for input
The bottom line is this – whether it’s a big 18-month tech project for a client you’ve known for two weeks or a two-hour Saturday morning project for your wide who you’ve known for almost 36 years, clarity and completeness in project requirements is critical. Anything less can leave you with lost revenue, profitability and time or on the home front… well that’s going to vary a bit with each relationship… but it could prove to be problematic for a couple days.
Readers – what are your thoughts? Have you had projects start with less than complete rand clarified and fully understood requirements? How badly has it affected your project revenue, profitability and timeline? Please share and discuss.