Identify Constraints
Constraints, like dependencies, affect how you plan the phases of your project, whether you’re working in agile sprints or a waterfall model. Constraints limit or restrict your options. For example:
The total time from start to finish for your project is eight weeks. Therefore, your project has a time constraint of eight weeks.
You have to integrate new software into an existing application. Integrating with a parent application is a constraint on the development options (platform, language, delivery) and your development team.
You’ve managed to tear a rather large hole in your briefs while rock climbing. You’d like to repair it, but all you have to work with is a broken spring from a carabiner and some frayed nylon cord. You have a problematic, but not catastrophic, constraint on available materials.
Types of Constraint
The most common types of constraints are those that limit the project's available time, resources, or budget. This is a challenge for the project manager. You have to find a way to meet the objectives or requirements in spite of the limited options.
Identifying constraints, like gathering requirements, is a fact-finding mission. Many of the decisions you make concerning the project will be based on the information you collect and document. If a constraint is too restrictive to overcome, it has a direct and negative impact on your ability to deliver the project according to the original requirements.
As you develop your client brief, you must document constraints in as clear and concise a manner as you do with requirements. Vague descriptions leave holes in the project that can lead to a failure to deliver. Here are a couple of examples of poorly written constraints, with better alternatives.
Time constraint:
Bad:“The project must be completed as soon as possible.”
What does this even say? Is there anything at all here that is helpful to anyone?Good:“The project must be completed and delivered by 6:00 PM on October 17.”
Resource constraint:
Bad:“Two part-time developers are allotted for this project.”
Well, we know how many part-time developers we can have, but we have no idea what defines part-time. How many hours can they work? Is it equivalent to one full-time developer? Can we get one full time instead? Where are the developers coming from? Is the client providing them from their own staff or do we need to contract freelancers?Good:“Two part-time developers will be provided by the client for a maximum of three hours per day for the first two project sprints.”
So, you have a good idea of how to identify your project’s constraints, and you know what it takes to write them with clarity, but how do you manage them and their impact on the project?
Document and Manage Constraints
Elizabeth Harrin, an authority on project management and the author of several books and the blog Rebel's Guide to Project Management, offers an excellent 5-step approach for documenting and managing project dependencies and constraints. I’ll paraphrase it here for you and put it in the context of our client brief.
Step 1: Create a Log of All Project Dependencies
Remember: A dependency is a condition where one element of the project is required before another may be started. Evaluate your project’s requirements and document all of the dependencies that impact your project. Create a dependency/constraint log (you can use a template or design your own). This log will become an important resource for your client brief, your continued interaction with the project, and subsequent documentation.
Step 2: Create a Log of All Project Constraints
Evaluate your project, brainstorm with stakeholders, and document all constraints that impact the project. You already created a log, so use it to catalog them. If you have a lot to document, you may wish to create two separate logs.
Step 3: Ensure the Major Dependencies and Constraints Are in Your Project Initiation Document (or Client Brief)
Do you remember the last question we used as a heading in the client brief? "What are the practicalities?" This is where the dependencies and constraints can be listed. If you have a lot, it may be necessary to document them in a separate document. In this case, select only the highest priority ones to include in the client brief, and then add a reference to the complete document where the others may be found.
Step 4: Ensure the Major Dependencies and Constraints Are in Your Risk Log
Most project managers have a separate risk log where they document the important risk elements in the project. As you read through your dependencies and constraints, determine whether any of them sound like project risks. Risks are those unforeseeable elements that are difficult to plan for, but that can have a significant effect on the project. A resource constraint, such as limited access to users for beta testing, could be defined as a risk and should be placed in the log.
If you know that a constraint is going to be a problem, record it in your risk log.
Step 5: Agree How You Are Going to Monitor the Dependencies and Constraints
Having an outstanding client brief and well-constructed logs is a good start, but writing great documentation won’t guarantee a successful project. You also need to devise a way to monitor and assess the dependencies and constraints as the project evolves and moves toward completion so that any impact on success can be quickly identified and addressed.
One way to do this is through a stakeholder management plan, or SMP, which we will discuss in the next chapter.
How About a Little Practice?
Remember your client, Christie? Here’s her follow-up email. She remembered a few very important things that she neglected to tell you in the previous message.
Hi,
It’s Christie again. I thought of a few more important things you should know. We want to keep our existing system but make it better. So anything you do has to be integrated into the current system. We can give you access to the codebase so you can begin from there. The system is an all-in-one solution for us. It’s a web app that drives our website, online store, human resources, payroll, etc. You name it, it does it. In some cases, it links to other products/systems to avoid reinventing the wheel. I'm not sure if what we want already exists, but if it does, include it in your plan so we can see if it will work with what we have.
Our system consists of two distinct parts: a backend built as a collection of APIs with ASP.NET, and a front end, including all web pages, built with AngularJS. We have multiple SQL Server databases for all of our data, and everything runs on MS Azure. Our app is currently on Azure’s P2 pricing tier. It performs OK most of the time. Will we need to upgrade with the new additions? If so, which tier would you recommend?
I forgot to mention that we don’t have a mobile device app yet. Our shoppers have to use the site via a browser. It works OK that way because the pages are designed for mobile, but we would like to have a designated mobile app for the online store portion of the system (if you can add it to the project). We'll need it for both iOS and Android devices.
I think that’s everything for now. I’ll let you know if I think of anything else.
Thanks,
Christie
Now take a few minutes to complete the following exercise:
Identify any constraints Christie has listed in this or the previous email.
Create a dependency and constraint log (you may want to do a little research online for some template ideas) and use it to document all of the constraints you can identify.
If you identify any of the constraints as risks, create a risk log as well, and document them as such.
Go back through the requirements you identified for this project in Chapter 2 with these constraints in mind. Re-evaluate them and determine whether any of them should be altered given the constraints.
If you alter requirements, note which ones are affected and in what way so that you can discuss these issues with Christie later.
Let’s Recap!
Constraints limit or restrict your options.
The most common types of constraints are those that limit the time, resources, or budget.
Constraints, like requirements, must be clearly documented; otherwise, they leave gaping holes in the project that can lead to catastrophic failure to deliver.
Effectively documenting constraints helps you devise a strategy for managing and working within those constraints throughout the project life cycle.
In the next chapter, we’ll shift gears just a bit to learn how to write a stakeholder management plan for Christie’s company.
