I’ve spent the majority of the last 20 years delivering IT projects for various Fortune 500 and SME organisations, more recently I’ve moved to a software sales organisation where I’m often delivering IT integration projects attached to enterprise software sales. The interesting clear difference between the former and the latter is when an organisation presents the integrator with a purchase order, it is normally associated with a commercially binding contract and is a totally transparent payment for expected service/product delivery.
I’ve spent the majority of the last 20 years delivering IT projects for various Fortune 500 and SME organisations, more recently I’ve moved to a software sales organisation where I’m often delivering IT integration projects attached to enterprise software sales. The interesting clear difference between the former and the latter is when an organisation presents the integrator with a purchase order, it is normally associated with a commercially binding contract and is a totally transparent payment for expected service/product delivery.
More + More = Less
The frictional relationship of more plus more equals less is better understood as both sides taking Oliver’s position and saying “please sir can I have some more”. To the client organisation this looks like the route to a better often more holistically aware solution that will be a better servant to the business. To the integrator this looks like a change of scope that will affect the services time consumed, the delivery date of the article in question and the perceived performance of the service team delivering the goods.
Some will say surely this is an opportunity for the integrator to make more money, as long as a good change management process sits behind the scope creep. Yes this is literally true, so why then is Oliver not well thought off by the dispenser of the porridge. Despite Oliver being a good boy who works hard, he still gets a slap for asking for more, moreover, generally the slap is administered by the person that writes the cheque and is invariably the master of the roles, not the person who has a holistic kumbaya view of the business.
So maybe the question should be how do you sing Kumbaya and also keep the person that signs the cheque happy, by the way what follows equally applies to anyone delivering services as an external integrator supplier or an internal IT/Project manager.
"Is that bus tread on your jacket dear?"
I’ve seen this many times as delivery times slip, the scope has dramatically shifted but nevertheless someone has to be thrown under the bus. The innocent cries of the agent of change are lost in the melee of those grabbing their teflon overcoats and doors slamming shut as would be stakeholders and influences flee the burning ship.
You would be told that the key to surviving this process is to clearly keep communicating to all layers of the cake throughout the project journey, keeping the cheque signer and the kumbaya group leader happy in a campaign of expectation management. However, availability and interest stirs for different stakeholders at different stages of the project and attention often wanes at seemingly innocent but nevertheless crucial junctures. Folks, don’t be fooled, your communications won’t be read in any more than headlines if at all and no one has the time to look back over what was sent and when, ruling out the 20/20 sanity of hindsight providing the forgiveness you feel you deserve.
So….the he said she said will have no currency regardless of how well documented it was. When the delivery date comes and goes, or the please sir bowl emerges from the agent of change you are still late and or over budget. Often without fault, a perception of failure will tarnish the agent or the service provider, coz net net , you didn’t deliver and guys/gals this affects not only the project you're working on but what or if you will get further projects/roles in the future.
Do you Waterfall take Agile to be your lawfully wedded…
So enough about who eats the mud pie and why, let us move on to how you become the mountain goat that climbs the loose slate hill of successful project delivery, whilst keeping costs controlled, delivery dates honoured and at the same time singing Kumbaya.
For me this is where Waterfall meets Agile, Waterfall will get me to the church on time, but might not have all the words for the hymns that will be sung in the service. Contrastingly Agile will involve every member of the congregation meeting regularly to maybe change the hymns that will be sung, so the service won’t run to time.
My answer is a marriage of these two seemingly opposing strategies, “nothing new there” I hear you say, “I have my hybrid play book working like a charm, what is so good about yours”? Where my marriage may differ to yours is that mine is not premised in creating a hybrid of two project delivery strategies, my marriage is more concerned about the perception of success of the project and the stakeholders involved, and how to keep winning without “asking for more”.
My default answer to what project methodology do you use is always “Agile off course”, I’m ever ready to extol its virtues without burdening the listener of why it’s not the panacea. After all you win no friends by maligning a model that is perceived to deliver successful outcomes. Contrastingly, the only place where you can say Waterfall these days and not be shot on sight or hailed as a Luddite is in a bank, a place where failure and risk tolerance is just not an option.
Imagine my facial expression when I was recently told that the current unnamed nuclear revamp project was using Scrum, yes I was being told this when it was 20 sprints past the original plan of 100 sprints, however I was also informed that the new missile decals were fantastic and had called on designers from across the globe, albeit through a rather protracted iterative process, nonetheless it has very shiny decals…Nice.
The Art of the steal
So..”yes off course I use Agile”, Agile with a difference, my project plan looks like a traditional one, with a critical path, industry standard slippage and some extra jet fuel just in case. My project task headers have the word Features and are made up of Sprints, they dont say stage anymore, the tasks themselves are backlog items, all Agile, typically Scrum nomenclature.
However, I’m extremely hard over “undelivered backlog items jumping into the next sprint”, I tend not to allow it, an all hands to the pump approach is used in a collective state of Sprint success, meaning all items in the sprint must be delivered to time.
Regular meetings with business stakeholders where rapid application development opens the door to changes or as a certain colleague of mine amusingly refers to these as CSS meetings (Colours, Shapes and S@~t), tend to elasticise the soft edges of the project scope, not once, not twice but many iterations and vacillations to an end point that might never be reached.
I tend to avoid these by focussing on very robust functional specifications at the start of the project, working extensively before the technical work begins to bottom out in Kumbaya settings how the new widget will look and work. Strangely, a widely accepted view of most project lifecycles is tied to when it starts costing significant money or time in development resources, organisations rarely start the project clock in the requirements phase, use this time to ensure your plan is solid, make sure the interim minimum viable products are well known and develop a solid understanding of how these relate to business delivery and ROI, trust me you will end up debating sprint item value later on so be credible.
The interface and business function served by the deliverable is often way more important in the perception of success than the technical specification, as this is what will be seen by the customer/client/user. Another way to think of this is how many times do you mark the plumber for his pipe work, as long as it doesn’t leak, you tend to focus on how nice the taps look, their ease of use and does water come out.
Spec + Change = New Project
My stakeholder check-in meetings are focussed on updating the clients as to milestones reached and to check that the actual business requirements are still the same, that the ROI for the business will still be achieved and that any dependant projects, milestones or other business initiatives will only be impacted positively by the timely delivery of the artefact in development, the latter answer keeping you politically agile and relevant.
Try to ensure that changes to business requirements are fundamentally identified as new projects, if possible always create a completely new separate project that stands on its own merits, if it has to, runs side by side or preferably after the existing in flight project closes.
This means that the original project delivery remains to time and will be perceived as successfully delivered. Additional functions or intersystem interfacing that was deemed to have enough business value to be worthy of a project mid flight, does just that, becomes a separate project or another potential win in the future.
The Net Net
Don’t let business stakeholders and technology evangelists get blinded by the art of the “new” possible, stay focussed on delivering the bird that’s in the hand, rather than trying to grab more birds from the bush. Attempts to boil the ocean invariably fail, so smaller project sizes are preferred, it is better to be known as the person who wins a lot of little battles, rather than the one who lost the war.
Use the time before the technical project work kicks in and nail what the business needs and how they think it should look and feel, remember this is the time that the business has amnesia over so it’s yours to maximise. As the agent of change speak fluent Agile but deliver like Waterfall, remember you are only as good as your last project, ask yourself was my last project on time and on budget, if your answer is YES then there’s nothing to see here move along, if the answer is NO go back and take some notes.