Whoever has been around IT projects in big Corporations knows that such projects are, at the minimum, painful and sometimes turn just into miserable failures. Original expectations are not met, costs exceed estimates, milestones are moved on and on, and the “product produced” leaves the end customer perplexed, disappointed, if not just angry. The reasons are different, different are the context, but you can often find the same repeated behaviours that pave the path to hell. And then, if you abstract yourself from professional day to day life, and look at what happens really on the ground, you see that this is all caused by Corporate world not being able to apply simple Common Sense, at least when it comes to IT projects. I want to tell you a story. It is about “Big Tough Company” which engages “Cunning IT Consulting Firm” to build its new strategic platform. I am sure you will immediately recognise that Common Sense never entered the game. Anyway, do not be scared. The story has an happy ending, at least a potential one. The background — Houston, we have a problem This is really critical “Big Tough Company” has a big, big problem. One of its core systems, BigMudBall, is getting old, it costs too much to maintain, it is almost impossible to evolve. Ever heard anything similar? There is no way out, they need to replace BigMudBall with a new brilliant state of the art solution. By the way, this has to happen seamlessly, without any disruption for the business of course. “Big Tough Company” starts an internal discussion to flesh out a bit more what this means, but unfortunately nobody has ever done anything even close to such a complex thing. By the way, it has been years since “Big Tough Company” has no employees with technology experience. No actually there are a few, but they have been left in the Dungeons and never nurtured with any management and decision making skills. Some of the experts of the many Consultancy firms that work for “Big Tough Company” are called in for an opinion about how to replace BigMudBall. All of them have done something similar, very similar, but in different contexts. Well, the contexts were so different that any real similarity disappear and very few lessons can be applied. They are of not much help now. Plus “Big Tough Company” does not want to share too many details with them, you know … they can abuse of them. Anyways, the big problem of “Big Tough Company” MUST be solved, BigMudBall must be replaced, and since “Big Tough Company” is notoriously tough, the problem will be solved in a tough way. To be tough, the first thing you need is a tough PM, who necessarily has to have a staff of tough PMOs. Actually, since the problem is big and complex, and many many things need to be kept under strict control, you need many tough PMOs. It is difficult though to find them within “Big Tough Company”. The ones they have are all already very busy running other critical strategic projects (but how many are the critical strategic projects of “Big Tough Company”?) and so “Big Tough Company” needs to get some PMOs from a specialised body shop partner they use for such cases. The Business Case: let’s build our virtual parallel world Virtual reality “Big Tough Company” is not only tough, but also very quantitative. Nothing gets done if there is not a solid Business Case. And there is a very well defined process to build such Business Cases, so that people do not get lost, and all precious data points are collected. First step in building the Business Case: interview the Tech Experts to get the data required. The Tech Experts are eventually found in the dungeons, and PMOs start asking questions, but the only thing they can get is that the problem is a big unknown, nobody has ever tried something similar, they have no clue whether a solution can be found not to mention how much it can take. The usual nerds, not able to raise their heads up from the keyboard, they lack a business vision. The PM eventually decides: “we, the managers, will estimate all the missing data points and come up with the best possible Business Case. By the way, we call in the “Well Known Business Consultants” firm to validate our estimates. At the end of the day, what can we do more? Who could do it better?” The RFP: we need a strong defence line, like the one Maginot built I learnt from the past how to defend The Business Case is precise. It dictates times and costs. Plus “Big Tough Company” is notoriously tough with its vendors, it just buys after tenders, it buys only “fixed price”. So the Procurement office comes in, to make sure a very tough RFP is built to support the Business Case. Yes, they know, there are great unknowns in the program. But, at the end of day, who cares: the Project must be completed and the Business Case met. We are tough, let’s move on. “Big Tough Company” is also smart, it looks back at past experiences. Yes, looking back at recent history, they reckon that many fixed price projects have derailed and took the Change Request trail, but this time it is too important to stay within the time and budget otherwise the virtual reality, oh sorry, the Business Case, will collapse. Procurement now gets creative, very creative, and takes the BIG IDEA out of the Hat: “We establish very tough penalties, and we will force the vendors to accept them — we know how to treat our vendors” They start the negotiations and eventually “Big Tough Company” wins. The Vendors accept all the tough penalties of the RfP, just the nitty gritty mechanics of how to apply them will be detailed later in the real contract. People at “Big Tough Company” are so happy for their first victory. How tough are these guys! The Response to the RFP: somebody is smelling the big fish There is something for me on the table In the meantime, the Vendors invited to the tender are very much attracted by the high pile of money behind the RFP and start getting ready. They receive the documentation: an incomprehensible patchwork which tries to describe the Big Project assembling many separate points of view, full of insignificant details and lacking a unitary vision. At the end of the day, nobody really knows how BigMudBall works and what it does. The unknowns are immediately clear. Vendor guys spot them at first sight. But the key thing is to start the intelligence to find out how much is the budget set aside. Once that is known, the right answer to the RFP will be assembled. Eventually the response is ready: the objective is to be economically appealing. It’s a difficult equilibrium point. You need to be below the budget, but not too much. You need to be lower than the average of the other responses, but maybe not the lowest. And what about the unknowns of the problem? How to deal with so much uncertainty, fixed price and schedule? No problem, Vendors have a very good medicine, it is called “assumptions”. As soon as any of these is not respected, the Vendor is entitled to renegotiate everything. And what about the tough penalties? They are accepted, certainly they are accepted, as long as “Big Tough Company” complies with a very reasonable set of requests. For instance: detail each big unknown in 1 week after it is discovered. Eventually the tender is assigned to “Cunning IT Consulting Firm”, one of the biggest in the market, people who work already with us, who know us. The path to hell has been prepared The end is quite clear The foundations for the disaster have been laid out: nobody has incentives to find the best solution to the real problem. Everybody is focused on defending their trenches, the fixed price and the penalties on one side, the assumptions and the client’s commitments on the other (plus the expected margin of course). In order to meet the tight schedule, a very intense and detailed plan has been devised. The army of PMOs has been reinforced to control every single minute aspect of the predefined plan. The secret for success is to raise the flag as soon as something starts going wrong. Flags can be actually raised, but unfortunately nobody knows what to do if a flag is raised since BigMudBall remains an unknown. Soon things start going wrong. The first meetings are called to discuss delays, but “Cunning IT Consulting Firm” raises also infringements to the assumptions and client commitments. The discussion gets hot, the clock continue ticking and there is no easy way out for “Big Tough Company”. The Business Case is there expecting the benefits to be released in a short time, we are in the middle of the river, stuck with this Vendor which starts complaining on us not being able to comply with our commitments. Control of the Plan: we need more status reports A frantic replanning starts. All the PMOs are asked to go around and ask everybody for new estimates, new completion dates, for all minor detailed tasks of the monster plan. We need to report to higher management, who needs to report to even higher management. The project status is daily on the table of the CEO. The amount of work people start putting on planning increases at the cost of productive work. The tight plan gets even tighter, it is clear to everybody that its schedule is impossible to meet, but still that remains the official plan, nobody dares to move the milestone dates. Status meeting are called on a daily basis to better monitor the program — all stakeholders need to be there, including the tech guys — some more time taken from productive work. One day then, in one of the status meeting, one guy, usually one of the most respected Tech guys of “Big Tough Company” can not stand any more the pressure of lying, raises his hand and says “ I can not meet my delivery dates”. There are lots of dependencies on this piece of work, actually everything is dependent on everything else. This means that the first milestone can not be met and the whole plan needs to be revisited. Big sighs of relief can be clearly heard in the room. A replanning, rescuing exercise starts with the objective to create the new hyper detailed plan — revision 1 of the Original Plan. Release 0: we went live, but we better start a stabilisation phase Something needs to be fixed These steps get repeated in a loop few times, until the project stumbles into its first delivery: version 0 of the the first part of the re-scoped, de-scoped, right-scoped scope of milestone 1. Just to be followed by a stabilisation phase, which means: stop every other development and fix all the bugs that slipped into production. In the meantime, in the background, “Cunning IT Consulting Firm” and “Big Tough Company” representatives are negotiating the first extension of the “fixed price with very tough penalties” RFP. The Aftermath: many suffer, but maybe not everyone And like that … he was gone Many people at “Big Tough Company” and “Cunning IT Consulting Firm” have suffered a lot, worked long hours and week ends, and frankly they can not be so proud of the outcome. Sometimes though there is someone who is happy. One may be the Controller of “Cunning IT Consulting Firm”: revenues never stop because projects never end, and when they officially end, then Application Management starts — margins are not really hit — multi year support contracts are seen on the horizon. And the Business Case? Nobody can find it any more. It must have been missing in action. Or maybe somebody finds it again. It can be useful to get promoted to a position made free by some of the casualties. It could have been different, if just a bit of Common Sense … What do we learn from this story. Here are some suggestions. Accept the unknowns exist and cope with them Agility saves Big complex problems are such because there are unknowns. As somebody said: there are “known unknowns” and “unknown unknowns”. The second specie lives and prospers in complex projects of these years. You may try to control the former with traditional risk management. But you should probably adopt agility to cope with the latter. Agility is actually the ability to react quickly to unknowns as soon as they become known, without pretending you can foresee them many months in advance (unless you are Merlin Wizard). Empower your Tech guys, your business is a Tech business They are the best suited to sort this out Every corporate business today is an IT centred business. If it is not yet, either it is going to become soon or it is going to face tough times. IT capabilities have been neglected for a long time, in the name of Cost Efficiency. IT seen as a cost center, something to be outsourced as a commodity. But now, if we look around, we see IT everywhere. And the Companies that have IT as their soul are the new stars, even too much of stars. If you still have Tech capabilities within your Corporation, please take them out of the Dungeons, understand how much value they give you, listen to them, make them active part of the decision process, nurture their leadership capabilities. If you do not have them any more, please plan to build them again. And do this soon. Treat the specialist you call to help you as your doctor, not as enemy I am your dentist If you need to call IT specialists to fill some strategic gaps you have, and this can happen, think of them as your doctor. You go to the doctor when you need help on things you reckon as serious. Strategic IT is a serious thing. When you choose your specialist doctor, you first look at somebody who you trust can solve your problem. Your first concern is not, or at least should not be, how to bring him to court if he makes any mistake. Treat your IT specialist partners similarly. They must be your partners, otherwise you should consider to just cut any relationship with them. We hope you enjoyed the story — thank you so much

Different

Erwin Rommel and his entire Army were agile, before the Agile Manifesto was actually written

Read My Stories

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

The story of the “Big Tough Company” and “Cunning IT Consulting Firm”

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Erwin Rommel and his entire Army were agile, before the Agile Manifesto was actually written

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

Erwin Rommel and his entire Army were agile, before the Agile Manifesto was actually written

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps