How do you best cater for change in digital projects?
We’ve all been there… The client wants a major change after they see the UAT site or worse the business case is changing at a rate of knots and you have to find a way to cater for it, NOW.
The best way to deal with change is to expect it.
Of course you can always throw more money or time at a project, and if the client is willing and able to do this that’s great, but this will do little for your credibility as a PM.
The agile approach seems to fit well with larger projects with more time and budget, where the approach is to build then check, then repeat. This very concept has ‘built-in change management’. However, smaller projects are generally are more suited to the traditional ‘waterfall’ method, where you only have one chance to get it right.
So what do you do when changes are thrown at you? First, breath.
Whichever methodology or approach you take to project management, be clear on the process for managing change from the beginning. Be aware that change is change, it’s different to issues or fixes for work which is off specification; and although we generally cater for a bit of change in the contingency budget, it actually requires a whole new or separate budget and often a new or separate timeframe if you want to have a truly successful project.
Set yourself up to succeed and be transparent with your client that changes will be needed. I’m not aware of a digital project that has not ‘changed’ at some point, so be bold and ask upfront if there is a budget for Change. If nothing else, this question will surely spark some kind of response and give you an indication of how too successfully manage or escalate the change requests that will inevitably come in.
The other thing to be aware of is the ‘sale’ of a digital project which is negotiated without any technical advice or influence. This can often happen in larger organisations who are engaging software vendors to deliver a pre-packaged solution for example. You can bet your grandma there will be changes needed at some point during the development or installation phase, because sales people are generally motivated by the sale, not the build.
The sales guy gets a high five, hand balls the project to the PM and goes out for Friday night drinks. Job done!
Hey, don’t hate the sales guy just yet, I’m sure they will have kindly included a ‘support and maintenance’ option in the sale!
Sounds ideal doesn’t it, but here is what will happen.
A few changes will be requested and some bright spark will suggest using some of the support hours to cover this. Great idea! But do want to be responsible for using up the clients post project insurance? Do you really want to take the wrap for the sales guys who cut the fat in the first place, and leave the project knowing the client is in debt for 4 months’ worth of support? No.
So do yourself a favour, expect change and plan for this inevitability the best way you can.
About the Author
Caralyne Blackburn Maglis is a leading technical project manager with an enviable track record in technical project delivery. Caralyne has worked in development companies, IT departments, agency and now in consulting providing Digital Rehab some of the finest honed experience and insights.
