Managing Projects through
Requirements

by Kathy Martucci, PMP:

As project managers, we are accustomed, even mandated, to planning our work and working our plan. We build and examine (and re-examine) Work Breakdown Structures and eventual project schedules. We swear our Gannt chart is our most important tool for tracking, managing and communicating. While this approach has led to many successful outcomes, is it the “end all and be all”? Are there alternatives to or variations on this tried and true methodology? I say YES.

According to PMI, there is no project scope (and, therefore, no project) without meticulous collection and vetting of any and all product and project requirements. There is no scope statement, no WBS, no schedule, no costs. This makes perfect sense – work for its own sake is folly, work geared to legitimate requirements is the means to an end, a defined end.

Requirements collection is, without a doubt, the most important work of the project. After all, without the requirements there would BE no project; the requirements embody the needs and wants of the project stakeholders. As such, excruciating care must be taken to define and document all the requirements with as much clarity and understanding as possible. Preferably, trained and experienced business analysts with clear marching orders and defined processes can accomplish this all-important task. Knowing what you know, you can plan an approach to requirements collection and management that will form the basis of everything else you do from that day forward. If the sponsor of your project wants you to fast track at this point, cut corners or otherwise skim the surface of the heart of the project, find another project.

Now, we aren’t naïve enough to believe that, once the requirements are documented, they won’t morph or take on nuances that were not understood initially. That’s all right; that’s why you continue to review and re-review as the project progresses. That’s why you undergo risk management and thoughtful communications. That’s why the organization has chosen YOU to shepherd the requirements to their full expression. That’s why you devise a plan and methodology for requirements management: a workable traceability matrix and accompanying processes.

In my world, the requirements traceability matrix is the cornerstone of any project large or small. The matrix not only ties each and every requirement to a legitimate business objective (defining “legitimate” must be documented and agreed-upon with stakeholders beforehand). Every other step in the project management methodology flows from the requirement / objective: the task and its activities to accurately and effectively address the requirement, the time to accomplish the task, the human resources to complete the task successfully, and any resultant procurement. I can’t state it too often or too loudly: every other downstream process in the project management methodology is moot or compromised when considered outside of the requirements management process.

The matrix, though, without processes to track and manage the requirements is useless. As the project progresses to the Execution phase, work should not be authorized unless it is deemed the right work at the right time based on the fulfillment of one or more requirements. Without a process to tie work to the requirements documented in the matrix, the methodology falls apart and serves no one.

Once you’re satisfied that the requirements have been solidified as much as possible, define the scope of the project. The scope should be based firmly and squarely on the body of requirements. It should be abundantly and unarguably clear to stakeholders what is NOT going to be provided either by the end product or in the project processes. Taking the time at this point in the project to communicate (and defend or confirm requirements AGAIN) with your stakeholders is part and parcel of stakeholder management and communications.

The Work Breakdown Structure (WBS) can only be built based on a deep and thorough understanding of the requirements. It may seem obscure that project team training will be part of the WBS, but if team members need skills to accomplish tasks that are derived from a legitimate business objective, it’s a valid work package…not just valid, but a critical success factor. Let’s turn that around: if your team is excited that they will get some training which is not necessary but will certainly enhance their resumes, they are in for some disappointment. That’s ok; it’s character building.

Requirements not only dominate the Scope Management of project methodology, it is the major driver for all other management processes. Human Resource management is dependent on the requirements of the project. If a cosmic-sized database is needed to accommodate requirements, a cosmic-sized database administrator (and the resulting costs) is justified. Hold out for the best; it’s a MUST.

Don’t have a super-sized database or the servers on which to run it efficiently? Procurements and procurement management will be driven by these requirements.

Lastly, “project quality management includes the processes and activities…that determine quality…responsibilities so that the project will satisfy the needs for which it was undertaken”. Of course, the “needs for which it was undertaken” are the requirements. Are we seeing a pattern here?

No, we’re not disrespecting or abandoning the WBS and project schedule; we are ensuring that these tools are driven and built by the requirements of the project, by the legitimate needs of your customer. Only then can the definition of a successful project include true customer satisfaction.

What methods do you use on a daily basis to manage your projects’ requirements?