How to Marry Business Strategy With IT Project Management And Why You Must
I've written about the need for business strategy and IT projects to be aligned before. I can summarise the thrust of all the articles that I've ever written on the subject with two words - it's critical. I mean, otherwise, what’s the point?
Yet, many IT Projects get greenlighted without sufficient business need and many others, that meet key strategic requirements, get mothballed or cancelled. In the case of the former, sometimes organisations confuse "nice to have" with "must have", and in the latter, IT teams sometimes simply fail to make the business case strongly enough.
Increasingly though I'm spotting a different trend emerge. For some IT Projects, business case is just REALLY hard to quantify.
Take these three IT Projects that my colleagues and I have recently helped to bring to life in one capacity or another. Which do you think was the easiest to prove business case for and which do you imagine was the hardest?
Project A - Key Goal - Increase System Reliability.
Project B - Key Goal - Increase Productivity and Reduce Cost of Business Processes.
Project C - Key Goal - Improve Customer Service Through Interactive Point Of Sale Touch Screens.
Most people I have asked believe Project B was the easiest. They are, of course, right. Demonstrating business case for Project B was like shooting fish in a barrel! Increasing productivity and reducing costs, especially when you can quantify both, are such obvious business wins. They're so tangible! The board, busting with enthusiasm, couldn't wait to sign this one off.
Project A and Project C, on the other hand, were harder business case sells. The customer service improvements delivered by Project C were hard to quantify but the system reliability project was like pulling teeth! In fact, Project A got turned down three times before, eventually, a convincing case was made.
So, in terms of obvious business benefit, the projects ran B, C, A in order.
Now, can you guess the order in which the projects would rank if the criteria were actual pressing business case? If you had to rank the projects based on how critical each was to organisational strategic goals - in what order would you list them now?
Interestingly, in these terms, the projects run A, B, C.
Note that the most critical project was the hardest one to prove a business case for. It was also the one that kept getting knocked back time and again. This highlights the challenge that IT teams are facing.
As we consider the solution to this challenge, let's first nail what business case actually means.
I like this definition. In "Making Technology Investments Profitable: ROI Roadmap to Better Business Cases" (Keen/Digrius, 2002) business case is described as a “justification for pursuing a course of action in an organizational context to meet stated organizational objectives or goals.” To be fair, this is roughly the definition used by most when either pitching (or assessing the need for) an IT Project.
The organisations that greenlighted Projects B and C had an easy job. After all, which business doesn't have a stated organisational goal to increase productivity and reduce costs!? The business that gave the nod to Project C has an almost 'Steve Jobs-esque' passion for delivering end-user satisfaction so, for them, an IT Project to improve customer service was also something of a no-brainer.
BUT, what about Project A?
Let's be honest. No-one has ever raised their hand at a meeting to put together an organisational mission statement and suggested "system reliability" as a key pillar. You don't walk into a business premise and read "system reliability" among the lofty goals painted in huge letters on the wall above reception and I don't think I've ever heard the words mentioned in radio or TV ads or in straplines beneath a company name on a van. To return to the Keen/Digrius definition, "System reliability" just isn't ever a stated business goal!
Without "system reliability" though, all your actual goals would collapse like a house of cards!
To you and I working in IT, this is obvious. You see the day to day business value that your IT infrastructure adds because you live it and you breathe it. It's actually a huge tribute to your skills that others in your business don't see this value straight away because it means that your IT is quietly and efficiently going about its business. Believe me, it's usually when the board knows you exist that you're in trouble.
So, when you believe that a project has legitimate business value you have to find the best way to demonstrate it! This means REALLY thinking about your pitch from the perspective of the business, the board and the managers who run the departments it will affect - and putting the business case, explicitly, in their terms.
This is what happened with the IT team seeking a green light for Project A. The business had enjoyed greater than forecast sales growth and to an experienced eye, the IT systems that delivered the growth were starting to creak (but still working well). What's more, from an IT perspective, business departments were operating as silos (and this was hampering further growth). So, the first pitch had landed on deaf ears because "improving system reliability" just didn't grab the attention of the board, the second (this time focussing on the departmental separation of IT systems into silos) was dismissed too - they just didn't get what that meant.
It was only after a major reframe that the board sat up and listened. The third pitch was slightly more apocalyptic! It focussed on the business consequences of not improving systems, it spelt out the cost and likelihood of downtime, the dangers of siloed IT systems not working together when stretched beyond their original designed limits and finally, on a more positive note, it outlined the growth that the improved, integrated systems would safely accommodate. This time the project was signed into life.
The value of business case/IT Project alignment lives on beyond the pitch and subsequent green light. There's a frisson of excitement around Project A now that it is live! Stakeholder and end-user engagement are critical to the success of an IT Project and in the same way that your board buys in when a project is pitched from their point of view, so too does everyone else along the lifecycle! As an IT user, if you tell me that systems are going to be down to improve "system reliability" I may roll my eyes at you but if I understand the benefits that your work are going to bring I'm interested.
The IT team working on this is more buzzed as well! Being honest, maybe they weren't as passionate in those first two pitches as they were in the third. Think about it, improving system reliability and knocking down silos are worthy endeavours, but they don't set the world alight! The way the third pitch was delivered makes the IT guys feel like saviours of their company and its future! They have a real purpose as they go about their work developing and implementing the project - what they are doing really matters!
And in conclusion, that's what matters - that it matters! Folks buy in when they can see and feel the value!
When there is no connection between your business strategy and your IT Projects, or when business case exists but is not clear, project failure risks increase, measuring success is harder, accountability is blurred and enthusiasm can quickly evaporate.
If you need help aligning IT Project ambition with your business need, often working with an independent third party, like a trusted IT Project Management Services partner can see connections and opportunities that you may have missed. After all, you work in your business day in and day out and so do we.
When alignment between business strategy and IT projects is explicitly defined and clearly established, even if all you're doing is improving system reliability, success becomes easier to measure and to achieve.
Sources : Researchgate.com