Capturing the Scope of the Project

Requirements are the lifeblood of any project. Communication with team members and the customer is key, and must be well thought out, well planned out, and – especially for larger projects – well documented. But good, detailed, and complete requirements are just as important – if not more so – because the amount of re-work that goes into the project later trying to fix work that was performed against poorly documented requirements will kill most projects in terms of budget, timeline or customer satisfaction (and sometimes all three at once).

There is no question that a key task for the project manager is to ensure that requirements are accurately captured for the project. In an ideal world the project client would come to into the engagement with perfect requirements but more often than not requirements are either incomplete or possibly even focused on a symptom of the issue rather than the big picture. That’s where the project manager needs to be ready – along with the  team – to ask the tough questions and spend some extended time extracting the detailed scope of the project and documenting the requirements so the solution can be developed against what the customer’s end users really want and need.

Identify the key success factors

Project objectives and deliverables are sometimes referred to as critical success factors. Critical success factors are those elements that must be completed in order for the project to be considered complete by the customer or even the PM’s executive management.  If your solution doesn’t cover these factors, then the project will never be considered a success. Not all deliverables are necessarily critical success factors, but many of them will fall into this category and should be documented as such.

Include stakeholders, SMEs and end users

Part of the process of collating requirements is going to involve digging a little deeper and reaching out well beyond just the project sponsor and immediate team. If the project manager and team are going to ensure that they successfully document requirements and deliver a workable end solution, then it is imperative that all project stakeholders, customer subject matter experts (SMEs) and end users be involved in the process of gathering, documenting, and finalizing requirements. If the data or processes are critical to the business it may also be necessary to enlist the help of a business process analyst with relevant experience to aid the process especially if you feel that a lack of experience might lead to a disconnect or communication breakdown between the different teams.  The more work that is done upfront in guaranteeing proper requirements have been captured, the less chance that expense rework will need to be performed later in the engagement. Change orders can often cover the cost of necessary rework, but change orders make customers less than excited about what you’re doing for them, so keeping extra customer costs to a minimum is always best. And of course, once the requirements have been captured in detail, be sure to have the project customer official signoff and approve of those requirements. Trust me, any questions that arise regarding project scope and requirements will be easier to handle if both sides have an agreed upon baseline to work from.

Things to remember

The bottom line is we need to work hard at the start of the project to ensure that what is being captured is as thorough as possible. And the key things to keep in mind are these:

• Don’t take the customer’s original requirements at face value… be ready to dig deeper
• Don’t be afraid to ask the tough questions
• Involve SMEs, other stakeholders and customer end users and try to involve business process analysts if you need to
• Document captured requirements well, get signoff and form a project scope baseline

And remember, that last one is imperative. Once you have the consensus that the scope has been captured, get it in writing and get it signed off. If you find out later that requirements were incomplete or have changed – going back to that sign-off will make the implementation of change orders much easier for everyone involved so that you can get back to the real work of implementing the right solution for your project client.