Scope of Management control System
In the ePMbook, we will try to use these definitions consistently. Remember that other people may be using them differently and that your team participants may be unfamiliar with the meanings. Try to make the context clear when you speak of "change".
Change is inevitable. During a project there will be many good reasons why things need to change. There will also be a few bad reasons - bad, but unavoidable. But there will also be many requests where the right answer is "no".
Let's consider some of those reasons...
Change Driver |
Comment |
| The business needs have changed | Business needs are changing ever more rapidly, particularly as competitors explore the new business models of eCommerce. All businesses must be willing to change if they are to remain competitive. |
| The organisation has changed | It is surprisingly common to find that the organisation undergoes some form of restructuring during the life of a project. This could involve mergers, acquisitions, being taken over, new departments, new business leaders, new products, new accounting structures, new locations etc. |
| Exploit technology improvements | The available technology improves constantly. All the time your Project Team are trying to exploit the various technology components, each of those components has a large team of people working to create a better version - and thus to make your version obsolete. |
| The organisation's priorities have changed | Although the scope and objectives of your project remain valid, the organisation may decide that there are other business needs that have high priority and should be addressed. |
| New business partners and channels | Organisations are responding to the rapidly changing marketplace by forming new business partnerships and alliances. New business channels are becoming available through those relationships, eg using industry hub portals and intermediaries. |
| New legislation and regulations | There may be unavoidable external requirements over which you have no control, such as new regulations for data privacy, changed regulatory reporting requirements etc. |
| Globalisation, standards etc | The organisation is making progress in presenting and managing itself as a global entity and, hence, there are new or revised standards for such things as website design, database definitions, corporate knowledge sharing, data warehouses etc. |
| Affect of other projects and initiatives | Other initiatives within the organisation result in revised needs for this project, eg there is a new accounting system so the interface from our new system will have to be changed. |
| We messed up | Or, to put it more discreetly, elements of the project's design and deliverables do not fully meet the defined need and will need to be re-worked. |
Why is there a distinction between scope change and other changes? In general, Project Managers should pay a great deal of attention to managing scope. Allowing the project's scope to change mid-course usually means added costs, greater risks and longer duration. Many projects fail due to poor scope management. Very often it is a large number of small scope changes that do the damage, rather than the big, obvious ones. The successful Project Manager has learned that rigorous scope control is essential to deliver projects on time and on budget.
The world-class Project Manager would not express this imperative in the same terms. The prime focus for the Project Manager should not be to deliver the agreed scope on time and on budget, but to optimise the benefit that is generated by the project. If that means allowing the scope to change then that scope change is a good thing, not a bad thing. It is wrong to resist all scope change. Where a scope change generates improved benefit, it should be proposed to the project's decision making body. Make clear the positive and negative impacts of allowing the change. Make sure the impact is fully reflected in the project's definition and performance criteria.
Watch out for the use of "scope change" as a defensive behaviour. In many cases, people will discuss scope changes in the context that a scope change is not the project's fault and must therefore be the business's fault. This is particularly important if the work is being performed by a different organisation under contract.
Share this article
Related Posts
Latest Posts
