Some tips to smooth the way for setting up the scope of a project

There are many literature pages about this, even magical methods and bullet-proof templates. Good luck with them.

I just want to share some tips and tricks that have been proved useful to me to do it smooth and painless.

Other phases have more prestige, like the Strategy, which get most of the long winded considerations. Other need more work and sweat to be done, like development. But the scope is the most delicate: is the nexus between desirable (goals, expectactions), feasible (limitations) and the definite thing (design, development, content). So treat her right.

Include the spirit of the letter

Your scope document is not just a list of features isolated from Strategy.

Include in it a brief statement of the big goal. This way you don’t have to think about everything. And this way other people (mostly third parties) don´t have the opportunity to cry “Oh, I didn’t know. I just did what you say”.

Always match features and content with business and communications goals

Everything you put in the scope you do it for a reason. This is not a letter to Santa Claus.

You can try the old trick to ask for more, anyway. The only manner to use this tactic with some posibilities of success is to indicate what is needed and what could be fancy to have. Hopefully, the latter will be used to bargain, but experienced negotiators will ample the deal to “needed”.

Get the right stakeholders in a room…

This is the trickiest part of the process.

Is not a good thing to prepare a slide-presentation-meeting with everybody involved right now. Not at this first stage.

The reasons are simple:

1) There use to be two main forces: Business and IT. Old friends, you know.

2) What we need now is the power of petit comité: No emails, no minutes, no endless public argues, no eternally unmatched agendas for new meetings.

At first, you thank the people for being here in this early state scope informal meeting. Then, you expose one by one the list of features needed to accomplish. One by one. Trying to discuss the whole thing becomes a mess.

Chances are that objections will be raised and needfulness will be praised.

Your job now is to facilitate, to translate and to be each other part devil’s advocate: As long as alleged problems arise, you have to translate or expose why IT objections are valid or “don’t touch my system” stubornness, and why Business are crazy coddled boy demands or wise strategic plans.

Stay calm and even-handed if you don’t want to be clashed.

…And leave them alone

Well, things will get political at some time. It’s an almost unavoidable law. You will recognize this moment because you start to not know what the’re talking about. The fact is that you don’t need to know and they don’t want you to witness. That’s why the blurry language.

At this point, I use to politely ask for the bathroom an encourage them to keep talking. Things are going well and we are having a great advance. And it’s true.

I use to get lost in corporate buildings. I look for cubicles with child paintings of dinosaurs  to breadcrumb my way back, but anyway it takes me fifteen minutes to find the meeting room again. It seems to be enough. The political game has been played, and there is little more to do than pick up the final score.

This not planning

You may be urged to scope, plan and gantt at the same time. Of course you will do all of this. But not before the scope has been approved. If someone wants to launch the project before or after the right moment, it’s their bet. Not yours.

This is not budgeting

Your job right now is to ensure that all needful stuff is included in the scope. But not before the scope has been approved. Then you’ll start budgeting. If someone wants to launch the project with less of necessary, it’s their bet. Not yours.

Assume nothing

Avoid assumptions. Make a list of things you take for granted and ask for confirmation.

Annotate dependencies

If the project have dependencies (prior job from other departments or divisions, support, reports, whatever), include them in your document.

Say who does what

Having everyone involved accountable for something, avoids liabilities in the near future.

Include the excluded

This is about other people assumptions. State clearly what is not included in the menu.