Grainger about IT-project management

Important when executing projects:

• Have a business case or a business idea that can be verified in an early stage.
• Remember to validate, learn and change during the whole process. When the project is finished you cannot change anything.
• Set-up SMART goals for the project before taking off.
• Focus on the end product to ensure that it will meets its demand.
• Never underestimate the value of being closely aligned with customer expectations.
• Use a way of staging the project. Whether it is Sprints or the traditional Waterfall staging it prevents the project to run bacchanal.
• Get the project budget, organization, and strategy right from the start.
• KPI’s during progress is a must.
• It is recommended that the project’s processes are tailored to suit the project environment, which prevents the project to be over-administered.
• Think your risk into the project plan on all levels.

Introduction

IT-projects are my specialty and my views are inflicted by the fact that I have worked with IT for more than 30 years. Project Management is the practice of initiating, planning, executing, controlling and closing the work of one or more teams to achieve specific goals and meet specific success criteria at the specified time.

And believe me, it is not easy! Why?

• First, all stakeholders and contributors must agree on what a project is and how it is managed. Moreover, an organization needs to be established.
• Second, they must commit to the mission, the goal and the success criteria of the project measured as deliveries.
• Third, they must commit to scope, resources, a timetable and all risks that come with entering the unknown.

All projects are characterized by having risks and some unexpected outcomes during execution – especially when we look at IT-projects.

One might say that Project Management is primarily about handling risk and eliminate politics, and this is the main reason for inventing the project organization. I think this is true especially when we discuss IT-projects due to my experience from working in major banks and public institutions where many projects are established. These organizations often suffer with employees and managers who will have different agendas and personal goals that are not coordinated and is just part of their daily life.

So, rule number one for project managers is to stay off politics. Leave that to the chairman of the steering committee and let him decide on political issues. And if you want things to move in a special direction try to persuade him before launching your views.

This is much easier said than done. But forming the right project organization can help a lot. Getting the commitment for scope, resources and the timetable will strengthen the project, even if it is managed in an agile way.

Rule number two is to use an existing Project Management frameset (PMP, PRINCE2) so the management, roles of responsibility and processes are in place before the start. Alternatively, you can create your own. However, this is costly and not recommended unless your organization has the resources and knowledge. Next, decide if the project should be Waterfall or executed agile or in hybrid.

I have executed projects in a broad range of companies and institutions, and I can support any kind of project from its beginning to it is fully implemented.

Some General Principles for Project Management

A common framework with principles and rules for managing the project is recommended in order to avoid risk and political interference.

One of the most used standard frameworks is PRINCE2 – for many years it has been the bible of Project Management. It builds on 7 principles, which are easy to understand and follow even though you have not taken the certification and read the 300+ pages Victorian manual.

PRINCE2 is created for any kind of project and can be used when you are building a new airport, creating a new pharmaceutical, establishing a conference, creating a new spacecraft or even developing new IT – if it is tailored a bit. Moreover, interesting PRINCE2 principles can as well be the foundation of agile projects without compromising.

But let us look at the principles as PRINCE2 describes them:

• Continued business justification.
• Learn from experience.
• Define roles and responsibilities.
• Manage by stages.
• Manage by exception.
• Focus on products.
• Tailor to suit the project environment.

The Project’s Business Justification

The cornerstone of any project should be a business case. The business case mainly describes the objective of the projects and its expected cost and benefits in measurable terms. Manage by stages is a way to organize the continued business justification focusing on the running cost and the expected return of investment, which will be discussed later.

If we turn against agile project managers some of the agilest will say that it is not true. They will emphasize that we should start with an experiment and create the minimum viable product, and then take the rest of the tour from here, not finishing before there is no more business value to achieve. And if not, then choose another direction. But that is, in my opinion, just another way of getting the business justification for continuing the project.

Project’s Objectives

Think SMART when you develop the project objectives:

1. Specific: Goals should be clear, specific, and well-defined. Vague or ambiguous goals can lead to confusion and lack of direction. Particular goals provide clarity and focus, making understanding what needs to be achieved easier.
2. Measurable: Goals should be measurable so that progress can be tracked and evaluated. Measurable goals enable organizations to assess their performance objectively and determine whether they are progressing towards their objectives. Measuring progress also helps identify improvement areas and make adjustments as needed.
3. Achievable: Goals should be realistic and achievable within the given timeframe and with the available resources. Setting overly ambitious or unattainable goals can lead to frustration and demotivation. It’s essential to set goals that stretch the organization but are still within reach.
4. Relevant: Goals should be appropriate to the organisation’s overall mission, vision, and strategic priorities. They should align with the broader strategic objectives and contribute to the organization’s long-term success. Setting relevant goals ensures that efforts are focused on activities that truly matter and add value.
5. Time-bound: Goals should have a specific timeframe or deadline for completion. Setting deadlines creates a sense of urgency and helps in prioritizing tasks. It also provides a sense of accountability and encourages timely action. Without a timeframe, goals may lack direction and momentum.

The business case must be based on existing business opportunities and company strategy. In this regard, a valuable tool is a SWOT for analyzing business opportunities.

The cost pays, together with time horizon, a crucial part in the business justification. If things go too slowly, it can ruin any business case.

There are a lot of free business case templates on the Internet but remember to adapt them carefully. One size does not fit all. Tailor them to suit your project environment.

You can obtain more information on how to work out the business case under “business development” in the main menu.

Most agile frameworks also recommend the SMART objectives.

 Learn from Experience

Being open-minded and curious are essential characteristics for IT project managers and project teams.

When creating something new, which is what IT projects often do, it is a good idea to give the project some space for experiments instead of focusing too much on standard methods, conventions, plans, and even the end goal. When we talk about IT projects, the end goal is often some kind of unclear vision that must come through.

Learning from experience can be carried out in many ways. Unfortunately, many of the ideas described in the Project Management literature do not work. Carrying out long reports about what was good and what flopped cannot be used before you enter your next project. And who cares, then?

However, it is interesting that in other areas like construction, it makes good sense to gather a lot of data that can be used in connection with upcoming projects. An example is the Danish Road Directorate, which can predict the cost of a new highway with high precision. It is strange that it does not work the same way within the IT industry. However, it probably works for a small portion of major mature companies, which have institutionalized data collection and built the result of analyses into their process models. But how many companies do we find at the Microsoft, IBM and CISCO levels?

For most smaller and medium-sized companies, selecting a massive amount of data is not an option. They will have to navigate within the unknown. Instead, they can implement continuous learning within their way of working. This is best illustrated by Inspect, Adapt and Retrospective used by Agile development teams.

The Retrospective used within Scrum provides the teams with a fast way of adjusting their way of working by focusing on efficiencies.

Define roles, responsibilities and organization

Roles and responsibilities are defined differently depending on the project’s characteristics. A typical organization could look like this:

Roles in a smaller project are often overlapping. The project manager is in most smaller teams, both Project Manager, Team Manager, and Change Authority.

Typical Prince2 organisation:

The most important is that the IT and the user organization, respectively, commit to delivering the needed resources so that the working teams can be manned and the project can be executed.

Agile projects are often organized differently, but in most cases, they hold some of the same characteristics – despite they work in another way. Comparing agile frameworks with PRINCE2 has been a long theoretical discussion for the last 20+ years, and I do not think anybody has reached a general conclusion.

If we say “Agile project”, we mainly refer to Scrum. But Scrum is not a project model. Scrum is more a way of organizing a delivery team. In smaller projects, the Scrum Team can become a Project Team. The roles of Scrum are few: A Product Owner, a Scrum Master and a team (6-8 persons with qualifications that suit the work). It is important to state that an efficient Scrum team consist of T-shaped developers.

Projects can be organized in many ways, but setting up a RACI matrix is a valuable tool for ensuring that the organization fits the project’s goal.

RACI is an abbreviation for Responsible, Accountable, Consulted, and Informed. It represents the roles and levels of involvement of participants in a project.

RACI is often used to link different processes in the project: change process, deployment process and basically whenever the project moves from one phase to the next.

Manage by Stages

Eating an elephant in one bite is impossible. It must be chopped in smaller pieces and some must go to the freezer before consuming it.

In many ways, it is the same with projects. PRINCE2 recommends that projects be divided into chunks so it is possible to plan what chunks to be delivered and when, and on that basis, monitor and control the project and hereby secure its continued business justification.

Theoretically, it makes a lot of sense, but in the real world, it is sometimes different. This way has worked for many construction projects but failed for most IT projects mainly because the stages have been waterfall-based – building from the fundament and up to the roof.

Man’s experience with construction goes back to when the Greeks were building temples and the Egyptians pyramids. But IT is different. IBM’s first commercial computer, IBM 701, was launched 29^th of April 1952. I think we sometimes underestimate the difficulties of using an old approach for something new. We take the old experience for granted – it worked for building houses, ships, and aeroplanes, and it will work for IT – but in most cases, it does not.

But is manage by stages totally wrong? The answer is no. You must reconsider what activities you define at each stage. Forget about defining the scope upfront, forget about proven technology, because the world is changing so fast that there is no clear scope. The scope, whatever you choose, is in most cases something else when you hit the launches’ date. Furthermore, the most efficient technology has also changed while executing the project.

So, what to do? Think agile and build your agility into stages. You can make your own framework suited to your organizational needs or you can adapt standard frameworks such as PRINCE2 Agile, SAFe or something else – most of the standard frameworks are less staged.

Manage by exception

All projects need have some controlling measurements also called KPI’s. The reason is that otherwise it is not possibly to monitor the progress. Some obvious KPI’s:

• Time spend in accordance with end-time planned.
• Cost in accordance with planned cost at point in time.
• Scope realized
• Quality in relation to agreed quality.
• Risk cost in relation to planned.
• Benefit – will the benefits of the project still be realized even some of the above measurements shows a great variation in relation to planned values.

By managing and visualizing exceptions senior management will get insight int the project and be able to be intervened if necessary (requested).

Focus on Products

The key success factor for a project is the product. Will it sell, can it be used, etc. For building a house, a new car model, a bridge or creating a new pharmaceutical product it may be right.

But IT-product is different because there are so many ways of solving the same problem. This means that we need to focus in a different manner when focusing on the IT-product. Most importantly, we cannot take it for granted that we can make all the decisions upfront when starting the project.

PRINCE2 says to focus on the production and not on the activities, but that does not work when creating new IT-solutions, in that case, they must go hand in hand. And we need to accept that sometimes we must go back and try something else to satisfy our consumers – that is being Agile, which is an important prerequisite for getting success. Never underestimate the value of being closely coordinated with customer expectations.

Tailored To Suit The Project Environment

This is a very important principle, as it gives your organization the freedom to tailor your processes. Forget about the PRINCE2 manual, which is focused on processes that are so complicated and Waterfall-made that they in most cases will never suit an IT-project.

This is the principle that gives room for agility, using Scrum, setting up sprint-based stages, experimenting with new technologies, etc., if everything is committed by the Steering Committee.

PRINCE2 is very ambivalent about this principle, as it undermines a lot of what is described in the manual. I think it has been made as a cat flap because PRINCE2 is so over-engineered with processes that cannot be tailored to use in the real world.

 Focus on risk and mitigation

According to Prince2 – strangely enough – it is focusing on risk and mitigation, not a principle as it should be, in my opinion.

All project management is about controlling risks and possibly mitigating them. That is why we work with a plan, a budget and KPIs. Trying to ensure that we will reach the benefits of the project as mentioned in the business case by the end of the day.

Did it sound complicated?