Project managers are an interesting crew. We often work alone, supporting our project team, usually without much training. That means some assembly is required to become a competent PM.
We often start out in some other discipline—typically development or design, and evolve into a project manager out of necessity. There’s a range of specific skills that we’re expected to have, but we can’t easily acquire. Without formal training, the skills we need only come from painful lessons, learned once we’re already in the trenches.
That was certainly my story—I’m an accidental project manager. If that’s you, and you’re managing projects without all the tools you think you might need, this article is for you. Let’s look at how to successfully control your projects, so they don’t surprise you and catch fire when you least expect it.
What does project control look like?
Initially, controlling your project is about planning and knowing the work you need to accomplish. The trick is that project needs and requirements shift over time. You learn more about the project as you go, and it’s normal to find the project exceeds your mandate. That means after the initial planning phase, it's important to be conservative when considering new priorities.
Adding new work mid-project exposes you to several dangers, including:
- accidentally overcommitting your team
- inadvertently shifting your delivery dates
- lowering the quality of the work you’ve already committed to deliver
It might be one big high-priority feature, or death by 1,000 feature requests, where small changes have a large impact. Either way, controlling how new requests are handled when you’re in the middle of a project is essential. Whether you’re working on a project inside your company, or as a vendor with one or more clients, you’re the one that keeps things on track.
Developers will push at you for more time to do something ‘the right way’. Designers will use their imaginations and invent features no one asked for. Business stakeholders will have ‘good ideas’. All of these war against the eventual completion of your project. Despite limited budgets and looming deadlines, it seems like everyone gets stuck in blue-sky thinking.
The thing is, they’re sort of doing what they’re supposed to do. But someone has to bottle all the creative energy and get everyone to finish the task at hand. Sometimes, the only one on the team that has the perspective to say “Good idea, but not right now!” is you.
So how do you control the scope of your project?
What can you control?
Much of what’s in this article is focused on vendor/client relationships, but it can be applied to internal PMs and their projects with a little creative imagination. Fundamentally, we’re all handling time, money, and the work that is produced by our team. Those three things are dependent on one another, in a relationship that’s often called the Iron Triangle.
The Iron Triangle is called that because the relationship between those three elements is fixed. Any change to one part (the amount of work you’ll produce) will have a corresponding change to the other two (the time or the cost of your project).
If you work inside an organization, you may feel like you have no way to say ‘no’ to your boss’s requests for expansion of your project scope. That may be true. Your best hope is to point out the Iron Triangle and express to them what their additional requests will mean to the time it takes to deliver your project, and possibly the opportunity cost of continuing to run the project while other priorities go unattended.
For those of us in client services or vendor role, it’s easier to say no, if you’re paying attention.
Your statement of work
When it comes to scope control, a written statement of work is your best and only friend, especially on a fixed bid project.
A well-executed statement of work (SOW) will have quantified measurements that give you boundaries to perform your work. Here are the kinds of controls that you might expect to find in a well-written SOW:
Responsibilities and assumptions
Good SOWs may also contain language that describes what the client is responsible for. These could be anything, but typical items include:
- dates of delivery for specifications, design comps, or other supporting documentation: "Design comps to be delivered on or before March 3rd"
- division of labor: "Client will handle all deployment and hosting-related tasks"
- descriptions of the general type and complexity of the solutions that your team will deliver
Based on those assumptions or responsibilities, you have the freedom to:
- alert the client that the project will need more time and budget if they are in danger of missing a deadline
- discuss options with the client when their requests exceed the SOW's intent e.g. if a feature was supposed to be off-the-shelf, and it suddenly requires a custom solution
- gently refuse tasks that are supposed to be on the client's plate
Quantifiable constraints
Quantifiable means a specific number—of hours, of pages, of features to be built, etc. These may be listed in the SOW itself, or in an appendix, typically generated from an estimation spreadsheet.
There's a ton of different things you can constrain in a SOW. What you choose to constrain should be based on what works for your team. My own experiences tell me a list of features, with written assumptions about how complex the implementation will be, is the best way to lock down what’s to be built.
That way, new features which are clearly not in the SOW can be identified. In the same way, features that turn into a black hole of complexity, or stretch beyond their specified implementation or level of complexity can also be controlled.
If your SOW has numbers in it that you can use to help control your project, you're in a great position to ensure a safe and positive outcome for everyone involved.
HEY! What about Agile?
If you’re a fan of Agile methodologies like Scrum, you’ve probably noticed that most of this article so far has been focused on waterfall or fixed-bid style projects. In an Agile project, you may not have a list of features or a SOW with quantifiable constraints. However, there is another kind of constraint you will have: sprint planning.
In an Agile/Scrum world, it’s typical to plan the next 2-4 weeks of work with your client. These planning exercises typically involve estimation and discussion about the work that your product owner prioritizes, to see how much the team can fit in over the next sprint.
It’s ALSO typical for clients to push for you to agree to more work than your team can really support. Scope control, in this case, means defending the slack in your developer’s schedules, so that they don’t face overcommitment and burnout.
In the same way, if your product owner tries to switch priorities on you in the middle of the sprint, your job is to protect the productivity of your team. If you can’t stop the last minute change, you can at least try to trade out an equivalent amount of work so your team isn’t entirely buried.
Manage to the SOW
To keep your project on track, you need to:
- Know your quantifiable constraints (SOW, or current sprint)
- Track your project according to those constraints
- Talk about those constraints regularly with your team, and the client
It’s almost inevitable that your boundaries will be challenged during the project. All kinds of risks and realities will arise—unclear business requirements, changing priorities, or unexpected conditions mid-project may cause a client to request additional work.
Here’s possibly the most important point of this whole article,
When work is requested in excess of the quantities specified by the SOW or is not covered in the SOW or related scoping appendices, it should not be undertaken without a change order.
As a new project manager, I fell down on this point over and over again. Don't be like me: Use your SOW to protect yourself. Not managing to your SOW is like intentionally cutting your brakes before going on a road trip. The worst part is that your team will take the hit for the promises you make—be sure to use your quantifiable constraints to protect them.
For Agile projects, as discussed earlier, mid-sprint interruptions violate the planning and productivity cycle. If prioritization of work on your project is that volatile, you might consider moving to a Kanban-based workflow, where the product owner can prioritize work as needed, and your dev team pulls that work into their process as they have the capacity. That way, your team can be measured by their throughput, based on priorities the client set. That puts the responsibility on the client to make up their mind, so you can deliver something of value to them.
Quantifiable constraints and assumptions tell you when you're succeeding with your project. If you lack a clear definition of done, or you don't have any tools to help you control your project, and you can't prevent scope creep.
Where can I get a SOW like that?
Many projects have failed because the SOW didn't have clear controls in it. If you find yourself in that position, you need to scream loudly to your boss, salesperson, or whoever can fix the situation for you.
If you're stuck in a SOW that doesn't have appropriate controls, you may just have to live with it. But it doesn't have to stay that way. The right kind of attention to quantifiable constraints and spelling out project assumptions during the sales process can make all the difference when you go to execute the project.
But my projects are internal!
Internal projects may not have a written statement of work, with associated budgets and deadlines. The thing is, you’re still on the hook if your project runs late. You still need protection.
You might try and publish a scope document for your project, and use it to say “Your request wasn’t considered originally. This is going to take longer”. You can be as loose or as formal as needed with your documentation, depending on the stakeholders you’re working with.
Try to get that written scope early in the project planning process, and circulate it to everyone who might make your life difficult later on. Getting scope agreement from your stakeholders early on might give you the means to push back when you need it later.
How to handle requests for out-of-scope work
All right. You’re mid-project and your stakeholders say “Could you just add personalized cat pictures to every page of the site, based on the location of each site visitor? Thanks.”
This is where you apply Darren’s first rule of scope control:
“Don’t commit to anything during the same meeting in which it was requested.”
Now, your client believes this has business value. You don’t want to flat-out reject their idea, even if the SOW doesn’t allow it. Instead, use the ‘Yes, and…’ technique. Affirm the value of that request, and tack on your condition or concern at the end.
In many cases, you’re saying, “Yes, and I’ll need more money to build that feature”. But it comes out like this:
“Geolocated cat pictures? Yes, I can see where that would be very important to your site. I’ll need to check our SOW and our current timeline to see how that might fit into what we’re already doing.”
Then you hang up the phone and go check your SOW. Don’t forget that part.
Once you’ve deferred the request...
If you’re lucky, your SOW contains a clause specifically excluding geolocated cat pictures. Problem solved. Now you can go back to the client, point to the SOW, and let them know they’ll need a change order for you to start on that work.
If you’re not lucky, the SOW doesn’t help you control for this type of request. At that point, it’s time to fall back on the Iron Triangle, and look at how this request will impact work you’re already committed to.
You can use that analysis and estimation to drive the discussion. It’s especially important to compare this new request against other priorities that are already underway. If you see the new request having a negative impact, say something!
Paperwork!
After discussion and possible negotiation about the request, the client may decide they want to move forward. Then you write a change order, sometimes with the help of an account manager, your boss, or whoever else might need to be involved.
Internal project managers, this is a good time to update your scope document and communicate about the change and its impact on your timeline. Whatever the case, written documentation of agreements protects everyone.
The worst thing of all is if you allow specific kinds of work (custom code, multiple design revisions that blow out your schedule, etc) that your SOW actually protected you from.
At the very least you should know those limits, and force a conversation that makes your stakeholder acknowledge they’re changing the rules. Accompanying documentation like change orders or revisions to scope documents should be executed once an agreement has been reached.
Whew!
To summarize, here are some things you should notice about smart project managers:
- They already know what’s in their SOW.
- They don’t commit right away when a new requirement surfaces.
- They use the ‘Yes, and...' tactic to acknowledge the client's business requirement while expressing the boundaries under which that work could be completed.
- They estimate the impact of new requests against present work, deadlines, and budgets and communicate that impact to the client.
- They negotiate how (or if) to satisfy the request and get the paperwork done.
- Document and communicate the change to everyone involved.
By contrast, don’t be accidental in your scope control.
- Don’t file your SOW away and never read it.
- Don’t agree to new work requests right away without consulting your SOW or your team.
- Don’t dismiss new feature requests without affirming your stakeholders.
- Don’t decide about requests for new work without considering existing commitments, deadlines and budgets
- Don’t allow verbal agreements. Get decisions written down where everyone can see, and communicate with all affected stakeholders.
The soft stuff
It’s all well and good to talk about managing to the SOW, but that can be hard to do. It’s scary. Sometimes, you don’t feel empowered to say no. Other times, you think you might need to have a hard conversation around scope or deadlines and don’t even know exactly what’s worrying you.
I’ve got good news for you: when you feel that way, uncomfortable and uncertain, you’re right at the edge of really succeeding in project management. This is your moment to get it right.
If you’re worried about something on your project, don’t just tell yourself everything is going to be fine. It won’t be. Don’t just work harder. It won’t make things better. Not unless you talk about those worries out loud to people who can do something about them. Use your concerns to drive your project’s success—your discomfort may end up being your best friend.
When you’re worried:
- Listen to your gut
- Talk about your worries with people you trust who can help you see them more clearly
- Once you’re clear, externalize your worries to your stakeholders in a proactive, professional manner, even if it’s scary.
You’ll be glad you did.