A challenge we encounter quite often when first working with new clients is defining, at a fairly granular level, a project’s scope. Often organisations know what they want in terms of high-level project deliverables, but have not gotten down to the nitty-gritty stuff – but that’s what we’re here for!
Project scope is the part of project planning that involves determining and documenting a list of specific project goals, deliverables, features, functions, tasks, deadlines, and ultimately costs. In other words, it is what needs to be achieved and the work that must be done to deliver a project.
It is important to pin down the scope early in a project’s life cycle as it can greatly impact the schedule or cost (or both) of the project down the track.
Below is an overview of some of the key processes to follow in order to define scope correctly.
Define the Product Requirements
Before we determine what will be in the project’s scope, you must be very clear about what are the product requirements, otherwise known as product scope. In other words, what are the functions and features required for the website, application and/or bespoke software solution being developed? Is there anything specifically that must be built into the design? Must it follow a specific set of branding guidelines? The list goes on.
Define the Process Requirements
Process requirements describe how people interact with a product and how a product interacts with other (often existing) business processes. When you discuss how data gets moved and how business transactions flow from one point to another, you are describing process requirements. For example, the requirements for billing transactions within a website, how such transactions link to invoicing and accounts, and at what point can staff view and alter the status of orders needs to be detailed.
Involve the correct stakeholders
It of course goes without saying that for a project to be delivered successfully, the correct stakeholders from the organisation commissioning the project must be involved very intimately at various stages of the project scope. When this does not occur, assumptions begin to be made (which are generally subjective) and stakeholder confusion can occur as the project goes on.
Identify the limitations
Perhaps even more important than what is in-scope for a project is what is out-of-scope for a project. Often it is crucial to document what will not be done, especially when it comes to software development – otherwise people will assume that certain things are to be executed that were not budgeted for or included in the project timeline.
Change Management
It is natural for parts of any large project to change along the way. While it is always best to avoid scope creep (a situation in which one or more parts of a project ends up requiring more work), sometimes it is unavoidable due to the changing nature of any business. In order to avoid disagreements and changes to a project’s scope by all stakeholders, both client-side and agency-side, it is best to have strict change management processes in place. Once scope is defined, it must not be changed without the appropriate change management functions taking place, at which point appropriate action can be taken to address the shifting project requirements.
So there you have it! A simple guide to getting your project off to the right start by correctly defining your project scope. At its very basis, effective scope management requires good communication to ensure that everyone understands the requirements of the project and agrees upon exactly how the project’s goals will be met. Once you have this bedded down, you have the foundation to commence and hopefully successfully complete your project.
