How to Deliver a Successful Project – Part 6 – Managing Changes

Posted in: Blog, Methodologies, Project Delivery | Jan 12, 2013 at 2:27 PM

No comments

INTRODUCTION

This is a series:

Part 1. What Does “Successful” Mean?
Part 2. Start It By Defining THE Business Requirements
Part 3. Accurate Estimates, Quoting and Proposals
Part 4. The Project Plan and Work Breakdown Structure (WBS)
Part 5. Delivery: Communication is Key
Part 6. Managing Changes
Part 7. Project Closure

MANAGING CHANGES

First of all, as part of this article: DOWNLOAD Business Requirements Document Template FOR FREE! Use it to produce variations and change requests document.

Changes always exist. It is almost impossible not to cater for changes in any project. Changes are good because most of the times changes make things better. In fact, I’ve heard of this wonderful quote:

A change may not make things better, but if you want to make things better there has to be a change.

So all changes need to be catered for and managed properly because otherwise, they will eat up your project time.

What is a change and how do we identify it? My definition of a change is any action item requested by either the client or yourself that is outside the scope definition described in the Business Requirements document. For example: the scope is to deliver a login mechanism that accepts username and password. Suddenly the client said to me, “Oh actually Tommy…can you add first name and last name field for checking as well?”. This is a change.

If you said, “Yes, I can do it” without treating it as a variation because you think it’s a five-minute job, then you are at loss. It means that you do more effort for free ie. the project hours is not increased, the deadline is not moved back and yet you still do the change for them. And not only that, you are introducing a new risk. What if the what-you-think-as-a-five-minute-job suddenly becomes an 8-hour job because it’s more complicated than you expect?

Therefore my dear readers, all changes have to be properly managed.

How do I treat a change (ie. out-of-scope items)? First I need to identify the type of change requested. I divide it into 3 categories:

5-minute change

This one I simply document in an email and send to client for approval and I’ll just do it for free. It only takes 5 minutes which is nothing. You keep the client happy and yet you are not introducing any risk. Example: Changing link color or font size.

50-minute change

Again, this is like the “grey area”. If I have a 50-minute change I will normally just document it in an email, send to cltient for approval then do it. Example: Changing banner padding size or add an email validation to the username field.

500-minute change

Now, this is different! I will treat it as a separate project, totally new project called a variation project. What it means is, I have to make another Business Requirements document, a quote and proposal, a project plan and the whole “shebang”. All the documents need to be signed off, etc. This way you will have a dedicated allocated time to do this change.

500 minutes (assuming that it is an 8-hour/day engagement) = 1 day and 20 minutes. This is a lot! Can you move the deadline by 1 day and 20 minutes? Probably not. So treat this as a separate project.

Example: Adding a new field to the user profile table. It may sound simple but imagine how much code changes there are.

SCOPE-CREEP

We often hear about scope creep. What is scope creep? Scope creep is just one of those “great ideas” that your client suddenly has in his mind (imagine a picture of a light bulb above your client’s head). For example: “Oh you know what…I think if we add a survey on the right hand column of the Intranet that would look good”.

You as the project expert need to quickly identify the type of change it is. If it’s a 5-minute or 50-minute job then you can do it for free but if it takes longer then you have to raise a variation or change request.

Scope creep often happens at a random time. Out of nowhere your client may contact you because he has an enlightenment that a great feature needs to be developed. Again, identify how much effort it’s going to be.

From my experience a lot of the time the client has no idea how long a particular “great idea” may take to be developed. Therefore, he will rely on you to tell him how much time it takes to do the change. If you simply say, “Yes, sir we can do it” then he will take your word for it. So be careful!

SCOPE-SEEP

Now, we also have scope-seep. What is a scope-seep? Scope-seep is an unnecessary complication that YOU INTRODUCE. For example, in a meeting, you suddenly say, “OK guys we have developed the login screen. I have an opinion, I think if we do double-opt-in and activation prior to logging-in it would be very secure and great”.

Whenever you introduce a feature, trust me, your client will take your word for it and will assume that you will do it for free.

Again, it is always good to suggest things as the more changes they agree to, the more work you get. But you have to be extra careful to not introducing too much changes and in the end you are the one who is entangled by your own “great ideas”.

CONCLUSION

All in all, a change is good. For me I’m always open for a change. It also means new business for me. The more changes my client introduce, the more work I have – meaning the more income I get 🙂

However, you just want to make sure that you are not adding an unnecessary pressure for yourself and your team.

Those who don’t manage change properly are bound to fail.

No Comments Yet.