Sometimes an idea is so simple you wonder why it is not uniformly used.

It was during a recent project management course that someone said that their company uses scope freeze as a tool to control projects.ice4

In simple terms, the scope is agreed with the client, key stakeholders and signed off by the sponsor or project board. Everyone agrees that the scope is frozen and cannot be changes unless…

Yes, the scope can be changed but only through a formal scope challenge meeting. This meeting has to be arranged by the person who wants the change (it includes the sponsor or any senior manager within the company). They have to explain why they think the scope needs to change.  There is then a general discussion on whether to accept the scope – the sponsor deciding.

Now I know you will say we have change control however:

  • Is it really working in your company?
  • Are project managers ‘encouraged’ to make the change without going through the change control process – just a small change here and a small change there?
  • Does everyone in your company see the scope as something set or easily moveable?
  • Do you actually have a formal scoping document such as a charter or a PID?
  • It is a great way to manage and control an aspect which is not always as well controlled as it should be

I think it is a simple idea that would and should work.

What do you think?


Picture courtesy of

This entry was posted in project management governance and tagged , , , , , . Bookmark the permalink.

5 Responses to Sometimes an idea is so simple you wonder why it is not uniformly used.

  1. Pingback: Sometimes an idea is so simple you wonder why it is not uniformly used. | #PMChat

  2. I think it is a sad indictment of project management that the concept of scope freeze is even necessary.

    As a consultant, I worked on many assignments for corporates, such as the BBC, EWS Railways and many others, where my job was to be the interface between the clients and technical staff. I had to define the client’s requirements for a particular major software development in a way that the client understood fully (and could signoff) and which was detailed enough for the developers to take up.

    I believe scope creep typically starts when the client wakes up in a cold sweat, halfway through development—or often later—and realises that what he has signed off (and is responsible for) will not actually meet his needs because A, B and C are wrong and X, Y and Z—which are essential—haven’t even been included.

    There then ensues the undignified spectacle of some people trying to change the project close to implementation while others try to resist; blame and recrimination are thrown around; profit is reduced (or lost altogether) and implementation is delayed.

    I think it is worth accepting as a principle that the reason this happens is always and only because the people whose job it is to assist the client define his needs doesn’t do a good enough job. And this is because they do not understand about psychology, particularly interpersonal communication, and don’t have the skills (and in some cases even the inclination) to enable the client to realise what is really needed.

    There is a second reason (but it’s actually a consequence of the first): the consultant (for want of a better word) is unable to articulate what has been agreed in a way that the client understands. The client doesn’t know that anything better is possible and won’t admit he doesn’t understand it. In any case, he thinks, we’re the client and we can change our minds later if we want. The consultant is only doing what his company and many others have always done. So, the requirements definition, or whatever, is signed off, with all parties unsure about whether it is fit for purpose. You don’t have to look further than the news of what happens to NHS IT developments to get this.

    (Of course, projects get screwed up for other reasons—usually insufficient and incompetent testing and poor day to day management—but we’re talking about scope creep.)

    Now, it’s not actually true that every instance of scope creep is due to a failure to define the requirements adequately before sign off. In the case of the NHS, for example, major project developments which straddle a general election are at the mercy of the new government’s different dogmas. Clearly, there are “acts of God” which create the need for scope change—though anticipating these can and should be part of the requirements definition. But these are so infrequent—and occur far less often than is necessary or believed—that it is worth taking, as a principle, that when the client changes his mind it is always caused by the consultant.

    The solution, I believe, is made up of at least all of the following:

    (1) all parties need to understand why, and accept, that more time and effort needs to be put into preparation than they think. Extra time and effort invested now, saves 10—a 100—times that resource later (to say nothing of the stress and anxiety reduced)

    (2) a methodology is needed which demonstrably can shift the client from their initial position of “this what we would like” (which is what they usually end up getting) to “this is what we, as people, need” to “this is what our business/organisation needs”

    (3) the consultant must be that relatively unusual person of someone equally at home in, and capable of communication with, the technical world and the client’s world (I appreciate I am focussing on IT projects here, but there is nothing I’ve said which doesn’t apply to any project)

    (4) the consultant understands that all that knowledge and expertise required for (3) are as nothing if he/she isn’t a good coach. In addition to the methodology, a coaching approach is essential if the dialogue between consultant and client is to get to the heart of the matter. But neither is sufficient on its own.

    (5) the consultant has to be able to describe back to the client what they are about to sign off in a way that is crystal clear to the client—not just to the individuals involved in the work to date, but to others (like the CEO, perhaps) for whom the draft requirements definition might be their first contact with the project.

    There is a perfect, and entirely true, story to illustrate some of these points here:

    And another story—this time a fable:


    • Ron Rosenhead says:

      Thank you Jeremy for putting in the time for your response.

      For me your reply suggests that this is a culture change issue. Some of the (positive) suggestions 1-5 above will certainly challenge some companies thinking. However, many people have told me of the additional bits of work that suddenly get added on however there are no more resources or money or time – simply more work.

      Good suggestions, thanks

  3. Ron, the approach I outlined removes all instances of additonal bits of work being added to the requirements.

    Deployment of resources (2) and (4) above ensures that the additonal bits are identified before sign off, so they can’t materialise later;

    When clients do believe they have thought of something new, a simple test against the question “is this is what our business/organisation really needs?” will probably show that it is actually “this is something I would like”.

    My approach was tried and tested with many clients when I was a consultant.

    If I were to say what the most important message is, I would argue that, if the consultant asks the client what the business needs and then delivers it, it is bound to end in tears. The client is not being obtuse or malevolent; but it can safely be assumed they don’t know what their business needs (and they certainly can’t agree what it is).

    Unless the consultant can deploy a coaching approach, the client will never realise that what they think is the problem isn’t.

    It doesn’t require a culture change of any sort in client land. The client is what it is. It probably requires a culture change in the service provider so that consultants can adequately be at the service of their client.

  4. Pingback: How do you counteract scope creep? | Project Management Training with Ron Rosenhead

Leave a Reply

Your email address will not be published. Required fields are marked *