In the current, increasingly competitive business environment and consequential reducing margins, almost every industry sector is being forced to aggressively control costs. As a result, the days of unlimited IT budgets and painless project justifications are nothing more than a long distant memory.
Against this backdrop, Managers and Project Leaders are subjected to ever increasing governance around the business justification for the activities that they are undertaking, and the benefits that they provide to the organisation. This is true of all departments that provide the supporting infrastructure that enables a business to function, but IT, with its perceived high costs seems to be under particular focussed scrutiny.
For many of us who have worked primarily in IT specific and often highly technical roles, the absence of a more general business grounding can be cause for a good deal of discomfort in the face of these questions. However, this does not need to be the case, as there is no secret to establishing a link between the initiative and the business benefit that it brings. It simply requires that IT leaders articulate what they are trying to achieve in a business context, rather than focussing solely on the technology.
In the case of a new project, there will typically have been a justification (such as a Business Case) written prior to its initiation. However, the link between this the project’s requirements and deliverables is often lost once the technical discussions begin, and thus the project begins to go ‘off track’.
It is essential that the Project Manager does not allow this to happen, and that the links between his deliverables and the business benefits, which justified the project in the first place, are clear to all. A useful mechanism I’ve used to demonstrate this link is the inclusion of business-oriented milestones in the plan, which allows project progress to be understood at a glance by managers, and those with a non-technical background.
Much of the art of running projects comes down to applied common sense, and here are the 5 simple rules for Business Value that I always try to follow;
- Describe the tools in the context of the business value they deliver.
- Link project deliverables back to the business case and monetary benefits.
- Add business-orientated milestones into the project plan.
- Structure the project to deliver incremental value throughout, not everything at the end.
- Ensure all change requests are evaluated in the context of potential business value.
Clearly the points that I’ve covered here are applicable to almost any Project, and so I’ll talk a bit more in subsequent posts about how we’ve applied the approach to a number of ITSM deployments.
In the meantime I’m always happy to share our experiences of implementing successful projects, so feel free to give me a call at Orb Data on +44 (0)1628 550450 or email me at firstname.lastname@example.org.