Properly Define Project Scope and Requirements

By Raleigh deShazo

This is the most undervalued project phase and the one in which most PMs and stakeholders allot an insufficient amount of time and attention.  Why?  I think it’s because we all want to see something being done, not planning on doing it.

This simple but critical phase sets the baseline for change control and allows you to more accurately communicate resource needs, costs, dependencies, gaps, and timelines.  In addition, it’s the launch point for your LOB client to start digesting the nuances between their current application and their new one.

Step one is to determine the requirements methodology for day one.  Common options are the following:

1. Like for Like. Short version – the client has the same functionality Day 1 as they have today with LOB acceptable changes.  Key risk – this can lead to custom enhancements which drive up costs and delay timelines.


2. Out-of-the-box. Short version – the LOB will change business processes as needed to accommodate application functionality. Key risk – timelines may be negatively impacted as the LOB reluctantly accepts and prepares for required Day 1 business process changes.  For this method to be successful, strong project sponsor involvement with an intimate knowledge of the current LOB processes will have to be in place.


3. Blended. This method also requires strong executive sponsor involvement from the LOB and IT with a stake in Day 1 functionality, the project budget and delivery timelines.  Key risk:  Project delays due to slow decisioning and inconsistent direction.

So, what is good business requirements definition?  That’s a good question.  It should be a document detailing the following:

1. Current functionality.


2. Critical Day 1 functionality – you need to determine early what can be sunset and what can be Phase 2.


3. Description detailing how the new application supports the functionality.


4. New vendor functionality – these can be target Phase 2 functionality, if needed.


5. Gaps – including decisioning on custom enhancement v business process change and Critical Day vs Phase 2.


6. Dependencies – what has to be in place for key functionality to work.

You are now ready to build a draft project plan that allows you to more accurately assess your resource requirements, potential costs, timelines, dependencies and risks.  For example, if you don’t like costs or timelines, you’re better positioned to make decisions that make sense for the company, i.e.

• Move non-critical functionality, nice-to-haves, to Phase 2.


• Leverage application base functionality vs custom enhancements.


• Add resources where positive impacts can be realized.


• Reset project expectations.

Next week, we’ll focus on adequately staffing a project and how to justify resource needs to executive management.  Let’s face it, most project resources have full-time jobs not related to your new project.