In the Iron Triangle: Avoiding Protean Scopes

Projects shouldn’t be free-form. You have to put boundaries around what you are going to accomplish.

The boundaries define your scope and you need a clear scope to determine schedule & cost.

Schedule, cost and scope are sometimes called the Iron Triangle because they are rigid and you can’t change one without changing the others. Your project manager (or IT manager) has to know all 3 parts of the triangle to deliver a high-quality project.

Small-midsize firms often start with ideas, throw a budget together and set a deadline. They say they want a new website, a new CRM or better lead tracking. They say they want it for a certain amount and by a certain time frame. But they don’t stop to thoroughly figure out WHAT they want.

Getting 2 out of 3 isn’t bad in most things. Yet a project without a clear scope is just an idea that you’re throwing money at and hoping to get done at some point in the future.

Start by Stating The Objective

It sounds simple, but the best way to move toward a clear scope is to start with a clear, written statement of your objective. In more formal PM settings, the objective is actually a requirement for starting work. You have to include it in either a project brief or a project charter. Most SMBs aren’t that formal, but getting your objective down in writing is where you should start.

Be concise, but descriptive when writing down your objective. Also, try to think in terms of goals. If there is a particular metric that you want to influence, then reference it here.

Typical Objective:
Build a website that is mobile-friendly, SEO optimized and allows for payment with credit cards.

Better Objective:
Build a new website to increase traffic and online lead generation via search engine traffic. The site should be mobile-friendly, especially for tablets and accept credit card payments on our site.

The 2nd (Better) objective gives a PM more to work with. It’s not a lot more information, but it tells us the goals and also points us toward requirements that we will want to raise with vendors or the internal team.

You can use the same approach for any type of project. Say what you are trying to do and how you are trying to do it.

Identify the Players

Your projects should benefit someone. Even if its a minor upgrade, the idea is that something will run smoother, do more, remove costs, etc. A great way to clarify scope is to think about the end users that will benefit.
Usual-Suspects-lineup

Let’s stick with our website example:
The new website should be easily edited and updated by the web team using a WSIWYG editor. All data should be automatically backed up to a server specified by our Web Systems Administrator. Transactions should sync with our accounting program and send a notification to the Controller.

Notice that I’m naming capabilities and who those capabilities benefit/connect with. By doing this, I make it clear who will be the final arbiter of quality & completeness. A key stakeholder may sign-off, but the staff are the ones that have to live with the solution. Thinking about the end user will help your PM narrow down the possible solutions and also figure out who needs to give feedback on different parts of the project.

Identify the Connections

Once you’ve got an objective and users, then you want to think about how your project will integrate with existing technology and processes. I hinted at some of this in the previous section, but here we put a little more meat on it.

Example:
The website should be able to integrate with Quickbooks for accounting, DropBox for storage, and MailChimp for forms and email marketing.

The key thing here is that I’m identifying legacy systems that any project will have to play nice with. Integrations are a commonly overlooked part of web projects. If you go with a custom solution, then you often have to budget for new or rewritten integrations to existing systems.

You will add a lot more to this section based on your internal systems and practices. Make a point of listing versions of software, whether its internal or 3rd-party, and if it’s managed by a specific group.

In the offline world, this might be the specifications you send to a part supplier, the HVAC compressors you use in your construction projects, or the size of the delivery trucks (or loading docks) for shipping.

Decide the Timing

Now you know the objective, the players and the systems in play. The next step is to put a timeframe around it. Sometimes it’s enough to say as soon as possible, but its best to define a start date and an end date. This allows you to coordinate resources and availability.

The project is to start on 1/1/2015 and be completed by 6/1/2015.

Honestly, giving exact dates can be a problem and create unnecessary stress. But at least give a specific month. If your organization has some key dates that you want your project to be done before, then make sure that you accomodate that.

Say What’s Out of Scope

Somethings should be out of scope. If we are talking websites, then maybe a micro-site isn’t going to be touched right now or you are going to stick with your old CRM even though you want to change it. What exactly is in or out of scope can be difficult to assess. This is especially tricky online because so many things are connected (or seem that way to stakeholders).

I can’t tell you what not to include in scope, but a good rule of thumb is to think in terms of systems. Connecting a new project to an existing tool is one thing, but if you have to rebuild, replace or redesign another system then it should be it’s own project. I know that’s sort of vague, but it’s honestly the best way to think about it.

As you’re building your scope, you’ll discover all sorts of things that have to be done in order for the project to succeed. Better to work through your project discovery and figure those things out than to add a bunch of additional projects at the start.

Identify Who Will Be In Charge

In charge can mean 2 things here:

  1. The very important person that has overall responsibility for the project.
  2. The PM or manager that is actually going to execute the project.

For both, you need to name someone. When considering #1, make sure that they have the authority to make most of the major decisions, sign checks and greenlight phases. Also makes sure they have access to higher-ups if something needs executive approval. For #2, they should be given a clear idea about their responsibilities. It’s not enough to name someone Project Manager, if you don’t give them and everyone else a clear idea of the extent of their authority.

Identify the Team

This one gets so many organizations in trouble. It’s one thing to know who needs to work on something. It’s another to make sure they know that they have to work on it. Make sure you identify the people that will be doing the work, whether they are internal or external, and how much time they should be putting on this. If you don’t do this, then you leave people to decide for themselves and many people will reflexively focus on their known, comfortable roles.

Figure Out How You’ll Manage It

Creating weekly reports or having standing meetings is a good way to keep things on track…but it can be a huge time-suck if people have other responsibilities. Talk with your PM, stakeholders and end users about how much time information and feedback should be provided along the way. Then find a good balance between information sharing and micro-managing.

A good way to do this is to determine communication frequency based on milestones, duration of phases or key deliverables.

Take time to explain how much information is needed for an update. If your exec team just needs to know the expenditures and that milestones have been reached, then let your PM know. If they are expected to walk-through the week’s activities and explain things in detail, then make sure that time commitment is understood upfront.

It’s also good to determine how updates and tracking will be shared. Will you use a spreadsheet, project management software or a weekly email? The format of updates can make a big difference in time required and ease of access/distribution.

Distribute for Feedback

The larger the project, the more diverse the set of skills needed to pull it off. Make sure that any key team members (including vendors) have a chance to look at what you’re trying to accomplish before the work starts. This will let you avoid scheduling problems, streamline communication and possibly give you some shortcuts that you would never know about.

Feedback also lets you get additional agreement about objectives. This is a CYA thing, but can save a lot of finger-pointing and backstabbing later.

Proof it, Finalize it, Sign it

At this point, you’ve got a scope statement: a clear declaration of your objectives, requirements, leadership, timeframe and team. Give this a few more reviews and then have the highest responsible stakeholder and the PM sign it.

A Good Scope Makes Everything Easier

Skipping these steps is how projects end up over budget and out of time. Depending on the size of the project, this exercise may take an hour or a month…but its worth it. Once you have a clear scope, your PM will be able to talk to identify tasks, layout schedules, estimate costs and get to work. Take the time at the beginning and avoid the headaches later.

Featured image from Wikipedia

More in planning, project teams
Shorter Project Phases to Focus on Key Deliverables

Web project scopes often require similar thinking to what HP is doing with their breakup plan. You have to think about...

Meeting Customers Early on the Path to Purchase

Content marketing can be a tough sell. You can explain the value of building content for buyer personas and developing an...

Close