100% Pass and No Plagiarism Guaranteed

WHAT DO YOU DO WITH BASELINES

What do you do with Baselines?

Throughout the project, you will measure the progress of the project, and use these measurements to compare the progress of the project against the baselines.

For example, you will compare what you have produced against the scope statement:

• anything that is on the scope statement MUST be produced
• anything NOT on the scope statement must NOT be produced

You will also compare your progress against the schedule baseline, the amount of money spent against the budget baseline, and so on.

You can also use baselines and progress measurements to forecast future progress and take corrective action, but that is outside the scope of this document.

But what if they want more?

As you progress through the project, the client may decide that the product needs more features, or something may need to be changed in some other way. Perhaps an extra column is needed on a report, or an extra program or web page, or you need to support more browsers. If you simply add these extra features at the client’s request (without seeking authorisation) this is called scope creep – the project scope (what will be delivered) is getting bigger, but no extra time or resources have been allocated for the increase - and importantly, proper investigation of the effects of making these changes will probably not have been done either, and so you may be greatly increasing risk.

So this means that the features the client originally agreed to pay for may not get done within the agreed time or budget, or may not work correctly, and you can be sure that the client will not accept the extra work and cost involved, they will simply blame you! So why increase the risk of your project failing doing work which was not formally agreed and which you will not get paid? Sounds unprofessional, doesn’t it!

Change Control

The only way to avoid scope creep is to always compare what you are producing with the scope statement.

If the requested feature is NOT on the scope statement, then a committee (or your manager) must calculate the impact (cost, time, quality) of adding the features. You must then explain to the client the consequences of taking this action, and now much more money and time it will take.

Then if the client decides that they want the changes added to the project scope, the existing baselines (scope, schedule, risk, cost etc) need to be changed as well – this process is called “re-baselining”. The processes in this section are referred to as Change Control.

But what if they want less?

It’s vital to remember that NO changes are free – somebody has to spend time and money to achieve them.

Even if the suggested change reduces the scope or the estimated time to perform, you will need to go through the change management process, get formal authorisation, then analyse and change all the existing plans. So it will still cost time, money and resources.

Who pays?

Theoretically the client should always pay for changes, unless the change is caused by supplier errors. But if you don’t charge the client for changes, then by default your employer is paying, and they won’t be happy about that. Of course your employer may agree to pay for the changes, but that is your employer’s decision, not yours.

Gold plating

There is another type of scope creep, which is caused by YOU adding more features to the product without the client requesting them. This too can cause all the problems already mentioned above. This type of scope creep is usually referred to as “gold plating”.

Typical gold plating could be - the client requests a program that will translate documents from English into German, French and Mandarin. But you decide you will give the client a special free bonus, by adding translation to Assamese, Bengali, Gujarati, Hindi, Kannada, Kashmiri, Malayalam, Marathi, Oriya, Punjabi, Sanskrit, Sindhi, Tamil, Telugu and Urdu. These extra translations are going to take extra time and money to complete this work, which tells the client that you overestimated the work in the first place to include these “free” extras. Such additions are therefore unprofessional.

Real Life Example of Scope Creep

A manager that I worked with (let’s call him Bob) was fired by his employer, after working there for 15 years. He had been sent to an organisation in another state to install and test a new suit of programs. When he demonstrated the system to the organisation’s managers, they said that the system required one more reporting program, to give them critical information.

Bob said that the program was not on the scope statement. The managers agreed, but said that they must have the program, and asked how much time and money it would take to produce it.

Immediately, Bob should have initiated the change management process and reported back to his office, so that the change control team could consider the change (and the impact of the change on the rest of the project) and estimate the cost. But Bob (an ex-programmer) told the bank managers that he could write the program himself in a couple of days, and there would be no extra charge, as they had paid a lot of money for the project so far.

THIS IS TYPICAL SCOPE CREEP.

Several months later, Bob was still in Melbourne trying to get his free, “two-day” program to work. But it never worked, it could never work, because it would have required major changes to the entire project – changes that the change control team would have spotted, if they had been consulted.

So because this free program wouldn’t work, the bank rejected the whole project, even though everything on the scope baseline have been completed as agreed. And Bob was fired.

FAQ

Q: How do I know when a project is finished?

A: When the project deliverable has been compared with every requirement on the Scope Statement and accepted (signed off) by the client (or your manager, if it is an internal project).

Q: What if I am managing a project and someone asks for something to be changed/added/deleted from what was agreed (the Scope Statement).