Earlier this month I spoke at a conference where I gave a presentation titled Scoping Digital Projects as a Non-Developer (slides from my presentation available here). Despite my presentation’s qualifier of ‘Non-Developer’ in the title, the principles of estimating the scope of a project are the same no matter what role you fill within your organization. In this post I will be offering an overview of a generalized scoping process that I have successfully used in the past. Though it is possible to go far into detail for each of the steps in the process, that will be covered in a later post.
First, a few assumptions:
- Methodology – The process of decomposing large, partially defined features into smaller, simply defined components and feature sets is necessary whether you are using a waterfall method, agile, or elements of both.
- Flexibility – This is but one method of scoping projects. I have worked on projects where other methods were successfully employed. You should always examine your process to make sure you are applying the right tool for the task.
- Client projects vs internal projects – Simply put, it does not matter. In my presentation I used a simple project for an imaginary client as an example. However, a commonly made mistake is not applying the same process to internal projects.
The Importance of Project Scoping
It is easy to think about scoping a project to simply answer “How long will this take?” But that does not reflect the true importance of accurately estimating scope. Judging what will go into a project (time & money, adjusted for risk) is really all about informing all of the project stakeholders of the facts so they can make informed decisions. That includes the project team and the client (along with their entire organization), among others. It is important to remember that no matter how much power the project organizer has, they still likely have a boss that needs to be provided information about where resources are being used.
Once the resources needed are identified, it makes the importance of scoping clear in another way: prioritization of features. Not once have I ever worked on a project where feature priority has not mattered. Sometimes features get cut to save costs. Sometimes a client does not realize that a low value feature uses significant resources. Almost always there is a new feature that is introduced by a stakeholder during the build process. If feature priority has not been addressed, then it is impossible to determine if or when that new feature should be built.
Client Communication
The initial communication with a client or project sponsor should be all about project goals. In this phase, the “why” of any project is more important than the “how”. The reason is simple, every member of the project team should be continually making decisions in support of the project goals. If there are tasks that do not support the project goals, then either the goals need to be restated or the task should be moved to different project (with a different scope).
Once goals are established, it is time to discuss any major limitations that any of the involved parties has. These often include:
- Designer and developer availability
- Budget
- Hard launch dates
- Contractual requirements, such as requiring that the client’s MSA be used
- Stakeholder review process
That last point, stakeholder review process, is important and often overlooked. It is easy for a project manager to assume that when their client-side contact approves a piece of work that the review process is complete. Sometimes it is, but sometimes the client’s CEO views the work two weeks later and requests changes. If a process for handling that work has not been discussed ahead of time, then serious problems could occur. Instead, establish how all parties will fit into the review and approval process. Be flexible if changes to that process are needed, but be honest when sharing how that changes scope.
Information Architecture
Whether a simple marketing website is being built, or a large and complex application, defining information architecture (IA) is essential for defining a project scope. The topic of information architecture is deserving of its own series of posts, so I will only cover it briefly here.
IA can affect scope by determining:
- What content is static and what is controlled by human
- What content is controlled by the software being built and what is dependent upon outside sources
- Who will produce content and who will actually input it into the new software
If an IA professional or an UX Designer is available to the team, it is important to engage them throughout the entire project, but especially when determining architecture. One of the simple ways to establish and communicate architecture is with IA documents. There are many different types and variations of IA documents, but I often choose from a short list of six. Often time, only a subset of these is needed and all should be modified to meet the needs of the project.
- User Flows – Defines how a user navigates a piece of software. Mostly used in applications with complex functionality.
- Site Map – A list of all pages and their hierarchy.
- Content Matrix – A tool to define content for all individual pieces of content on a site. Can take many different forms.
- Wireframes – The ‘blueprint’ of a site or application completed before design is undertaken. Often overlooked once hi-fi designs are provided, but should be referenced throughout the project.
- Feature Descriptions – A list of all important features, their functions, and their goals. Can be a general “executive summary” or very detailed.
- User Stories – Highly depended on the project management methodology used, but generally a list of tasks that users will be able to perform.
Decomposition Into Components
This is the heart of estimating the scope of a project, regardless of what methodology is used. By breaking a project into smaller parts, we can more accurately gauge the time needed to complete a component and the risk associated with that component. The concept is simple, estimate individual components of the project in units of time that all parties can understand and be confident in. My preferred unit of time is four hour increments, so any component will take 4, 8, 12, 16, 20, etc., hours. Small features that individually take less than your unit of time can be grouped in “feature sets”.
All components and feature sets should be able to be estimated and discussed as discrete items. They should also be important and easy to understand for all stakeholders. If a client does not understand what a certain component is, then that is a an opportunity for an important discussion. Breaking the project down into these components makes it very clear which features support the project goals and which do not.
Risk
How risk is managed within a project can vary a great deal depending on factors such as client requirements and project management methodology, but it is always important to identify. Estimating the risk involved with a project as a whole is often focused on the consequences of the potential outcome instead of the likelihood of that outcome. “What happens if this fails?” and “What happens if this goes over budget?” are important questions, but are only part of the equation. That is one of the reasons why decomposing a project into components is so important, it allows for the estimation of risk of individual portions of the project.
Different methodologies use a wide variety of ways to communicate risk, but a very simple way is to just assign a low, medium, high rating to each component and feature set. How this identification of risk is used depends on the project, but the exercise is important in itself. An example might be a component called CRM Integration, where the developer has to integrate the new software they are building with the clients chosen customer relationship management software. CRM integrations can be simple and low risk, but in this case it has been identified as high risk because the developer has never worked with this particular CRM and there are reports online of it being a difficult and poorly documented tool. At the very least, identifying this high risk item should prompt a discussion with the client on how to lower the risk of this integration.
Presentation of Scope
Once the project has been estimated to a high degree of confidence, it can be presented to the client with all the supporting documentation. Ideally, the client and other stakeholders have been involved in the scoping process and this is just a formality. It should be stressed that the project will be most likely to succeed if the scope is flexible. Things will change throughout the project and that will have to be clearly communicated when it does. When something deviates from the plan, have an open and honest discussion with the stakeholders. Let everyone know what happened, and how the plan is changing to address the deviation.
It can be daunting to estimate the scope of a project, but following this general process can greatly simplify the task. Discuss goals, use IA to define content relationships, and decompose the projects into components to estimate cost and risk. I am more than happy to discuss any of these concepts if you have questions. Please feel free to reach out to me via email or on Twitter.