Just about a year ago, the economies of the world were steaming ahead at jet pace; today the global economy is slowing down and we are talking of a world wide recession. Less than a year ago, the cost of a barrel of oil was sky rocketing at $150; today it is down to around $50 per barrel in the global market. Times are changing & changing fast. We can deny its existence as much as we wish to, but the truth of the matter is that change is all around us. And no one, not even our projects is immune to its effect. I mean, forget the changes in the global environment, how many of us have escaped the clutches of changes requested in project deliverables while the project is in progress?
You are probably saying “Tell me about it! No sooner than I plan for one situation than one change request turns the entire situation over its head. As if life wasn’t difficult enough already!”. I couldn’t agree more. Here we are, following PMBOK’s guidelines to the T, armed with half a dozen plans of how to manage different process areas and one single alteration, one change request from the client turns the entire thing upside down! Now is that fair?
Probably not. Truth be told, many of us would probably prefer that requirements be frozen, that status quo be maintained & that we go about our projects in an routine manner. But where is the fun in that? Are we losing out on more exciting opportunities by pulling ourselves within comfortable and familiar surroundings? Would we really be glad if our projects followed a typical beaten path or are our intellects insulted by the absence of fresh challenges in the environment? Maybe…just maybe…
OK, so maybe, change is inevitable, change…well, it changes things and change is to some extent even welcome, but there has to be a way out! How do I keep my project from getting affected by any & every change that comes by? Will these pointers help?
1.Try & minimize change
Am I asking for the impossible? Not really. I am not trying to prevent change or ignore it. I am simply trying to minimize its occurrence. How do we do that? The Requirements gathering phase plays a crucial role here. The project’s success depends on the efficiency with which the requirements are elicited from the various stakeholders, analyzed & documented. These requirements form the basis for all future work plan, costs, schedule and quality parameters. So go all out during this time to ensure that every small need & whim is collected, analyzed and properly recorded. And ensure that you use simple & the right language in documenting these so that all parties involved agree that this is what the project is going to achieve & this is what it is not. Now is not the time to display your superior verbal skills.
2.What else but Plan…for Change Management
The Change Management Plan is probably one of the most neglected but of the most useful documents. Of the various important points that need to be recorded in this plan is the definition of a change, of a threshold change value beyond which the change management process will be triggered. Also included is the whys and wherefores of the change management process – who is authorized to issue a change, what are the response times required for the analysis, who will approve the change, how will it be carried out, how will changes be prioritized & integrated and so on. Lastly, a plan is only as good as its implementation and never before. So beware the tendency to mothball this plan into the closet; use it to realize its benefits.
3.It will arrive in the next train
Aside from the fact that changes are bound to turn up is their annoying habit of turning up when things are moving at full throttle. Analyzing and accommodating the new request at this time is probably the last thing you would wish for. Talk to the change initiator about how serious is the new requirement. Is it something worth jeopardizing the present deliverables? Is there a scope to complete the project in its present form & then add on the new request as an extra feature, if technically possible?
4.Use a tool, you fool!
More often than not, projects run with an ad hoc set up. Changes come in and are squeezed into the deliverables on hand simply by word of mouth based on the relationship between the different parties and never recorded anywhere. One can only imagine the confusion faced by a new entrant into the project trying to figure out where & how this change came up. There are multiple configuration management tools that are available suited for various project needs. Use of such tools not only simplifies the entire process but also makes it more transparent. And remember, a tool has no brains of its own, so use it wisely.
5.Give way
No, I am not asking you to give up everything & leave the project. Every project has a unique deliverable & you are the most informed of the same. Ask yourself well in advance “What is it that can change in this?”. And then build in some amount of flexibility to accommodate the anticipated change. Such parametrization yields great benefits! After all, if A can change to B today, what is to keep it from changing to C or worse, returning to A the next day? Parametrize and A can change to Z tomorrow for all you care, you will be able to handle it!
