Refining the process of delivering IT projects
A very wise and trusted colleague many years ago said to me that to effect change, the first step is to tell people you are thinking about change. The second step is to say what sort of changes are being contemplated. In line with this, and Ghandi’s philosophy of “We must be the change we wish to see”, the project management community seems to be thinking about change, at least for projects that have a significant IT component.
Although I am not an IT person, I have been involved in and have run projects that have significant IT changes, mostly regulatory. They did not involve IT procurement. I have observed many of these issues, sadly been responsible for some of them, and empathise with the IT-ers whose constant refrain is ‘where are the business requirements?’ and who are always the people who are ‘concertina-ed’ at the back end of a project.
Identifying the issues
Coming up with a solution where you have not properly defined the issue is a recipe for disappointment. In fact, in the project world, it can be the core reason for project failure. The observable issues include:
- Lack of project management practices and skills, resourcing and clarity of roles
- Dealing with the uncertainty that is an inherent part of projects
- Lack of strong and experienced sponsorship, clear decision making and lines of authority
- Absence of business value and validation
- Inadequate scope definition
- Inadequate planning
Imagine if:
- The project came in on time, on budget and within the scope originally agreed at the time of initiation of the project;
- The outcomes earn the business the income expected;
- All members of the team are genuinely pleased with the outcome and their individual contribution;
- The person leading the project feels supported throughout the process;
- Everyone impacted by the work or interested in its outcomes is aware of what the project is doing and are confident to make decisions when required;
- Those impacted by any changes understand what the project is doing and how and experiences a smooth transition to the new world.
Compared to many other types of projects, IT is but a toddler. How do we make this vision real for IT projects? Or is it a pipe dream?
What is an IT project?
All projects are for the benefit of the enterprise and its customers. Even if the project has been established to replace an archaic system or decommission a system, this principle holds true.
How can we learn from far more established areas of project management, such as construction, and still put a modern face to it, such as Agile?
IT projects are more conceptual. As you build a house, anyone can stand back and see how many bricks have been laid, how far there is to go to completion. Most people can read a floor plan. This is not the case with IT projects, which are far less tangible and where only a handful of people understand the floor plan and observe and understand the IT bricks as they are laid. IT projects are different because they are not mainstream business as is often the case with construction projects.
IT projects have a different ‘way of being’ compared to mainstream business but they have very profound interdependencies on the mainstream business for their success. It is therefore incumbent on both business and the projects to build bridges of understanding. The earlier the understanding is established the better.
It is therefore critical to actively engage the business, always being aware that the purpose of—and outcomes from—engagement must be clear. It must always be borne in mind that people within the business have a day job. In this phase, you must always be two steps ahead so the business can be guided through the analysis and decision making phase.
The differences between projects and mainstream business and their interdependencies become increasingly easier to manage as project maturity increases within an organisation. Ideally, the understanding should be institutionalised, that is, not reliant on any single project, but organisation wide.
