In 2016, the Harvey Nash/KPMG CIO Survey noted that IT project success rates were declining.
In 2017, the updated survey probed more deeply into project performance and revealed what, to many, may be a surprising rationale for project failure.
Project failure is largely due to weak ownership, rather than a lack of project talent or budget
To many this is extraordinary as, at the very outset of any project, considered attention is given to ownership. Few organisations would start a project unless there was an approved Project Initiation Document (PID). This document gives, among other things, a clear articulation of sponsorship, roles, responsibilities and governance in general.
So, what’s going wrong?
The seas and scale of change
As projects become more complex and challenging to deliver (multiple stakeholders, pace of technological innovation and access to skilled resources, to name but a few) many projects struggle to keep up with the corresponding scale of change.
If the business case, requirements, stakeholders and internal project team all remained static during the project lifecycle, then ‘ownership’ would be a non-issue: it would be clearly defined at the outset (as it always is) and remain stable throughout (as it never does).
You could sail the Atlantic in a canoe if the sea is totally calm. And you could breeze through a project if the project environment remains fixed. Neither scenario, though, is realistic.
To get safely across the Atlantic you need a sturdy ship. To overcome the choppy waves of disruption all projects need an approach to project management that fundamentally recognises that change is going to happen, and happen unpredictably.
Two ships to sail
Many organisations deal with external change in two ways: by applying an iterative agile development approach and by implementing rigorous change control.
Agile development certainly improves the chances that what is delivered will be readily accepted. Project uncertainties will be captured and dealt with during the development phase, rather than spotted and recovered during the final user acceptance test.
Rigorous change control helps keep the main project on track, deferring enhancements that could jeopardise the timeframe for later releases.
However, these approaches only handle external change. What about internal project change?
Most change control processes zoom in on the financial and timeframe impacts. They pay little attention to whether the change requires an adjustment to the stakeholder map, communications plan, or any of the other considerations that the original business case and PID assumed. No wonder ownership weakens as projects progress and it becomes the number one cause of project failure!
Furthermore, it is to be expected that key team members, including the Project Manager, may have to be swapped out at some point. But all team members can be regarded as ‘key’- all stakeholders across the board. There is no such thing as ‘just a tester’ or ‘only a user’. Everyone has a role to play, and when a stakeholder leaves, no amount of transition planning will fully make up for the loss.
Unless, that is, the project takes a more collaborative approach to project management.
Collaborative Project Management
The long-standing tradition of attending meetings to get an update on project status, of managing risks and issues through spreadsheets and a heavy reliance on email to communicate all manner of things – requirements, updates, reminders, complaints and so on – no longer cuts it.
Not only does this approach make it virtually impossible for a smooth handover in the event of someone leaving, it also makes it virtually impossible for the existing team to keep on top of what is going on.
A far better approach to managing internal project change is collaboration, which is as transformative to project success as agile methodologies have been to handling external change.
Instead of accepting that not everyone will be able to attend each and every status meeting, and that not everyone has the stamina to read each and every email to adjust their understanding of what’s changing, collaboration tools provide a central point for project communication – and control.
NashTech uses several collaboration tools to support project management. Aside from the usual benefits expected from Sharepoint and Skype, our project teams make extensive use of Jira.
This tool strips away the traditional reliance on spreadsheets and update meetings by giving contributors (developers, testers, project managers, etc.) direct access to a shared repository for tracking project progress.
We use it extensively to raise bug reports and project issues, which can be submitted along with detailed annotation notes. Workflow, coupled with voluntary requests to be notified of specific project changes, enables the right people to know about what impacts them – or what decisions are required from them – which greatly increases the flow of information.
Moreover, it helps speed up the decision making progress – and as every project manager knows, it’s often the speed of making decisions that determines how successful the project will likely be.
To learn more about NashTech’s approach to project management and the solutions we are deploying for clients worldwide, please contact us today.