Implementing a Project Infrastructure

Author: Neville Turbit

Overview

In working with a client recently, proved an interesting experience. The way in which the organisation decided on, and undertook projects was less than organised. I have used the term “Project Infrastructure” for a number of years to describe the support mechanisms for projects, and in this case it did not exist.

For example:

There was no definitive list of proposed projects.
There was no way to determine the priority of projects.
There was no consistent process for managing projects.
There was little in the way of material such as templates to support Project Managers so they all invented their own.
They had “bodies” rather than specific “skill sets” to work on projects.
They did not know when many of the projects would end.

The situation was typical of a mid sized company who had not devoted the time to put a project infrastructure in place.

There was lots of work to do, but where to start? The answer was “in lots of places”. We would need to move a number of activities forward in parallel. The next question was how to explain this to management?

The Project Infrastructure Map

At this point, I needed to develop a map of the work involved in order to explain the approach, and gain agreement to the big picture. I came up with some generic components based on:

What – What work do we have?
How – How do we manage it?
When – When will it be done?
Where – Where is it up to?
Who – Who will do it?
Why – Why are we doing it?

In order to answer these questions, we need to put in place a number of building blocks as shown in the following diagram.

I will go through each box and explain what is involved.

What – What work do we have?

Project Register

Somehow you have to put a funnel on the project pipeline and get everything pouring into that funnel. That usually requires two activities.

The first is to round up all the existing projects, ideas, concepts and put them on a list – or better still into a project register program. Your service desk software may be another tool to use to log the potential projects.

You need to capture basic information such as the business problem, the expected outcome, is it big or little, who are stakeholders, proposed solutions (if any) and who initiated it. In our case we came up with a list of around 150 after we de-duplicated the list. Some went back a couple of years and we could only find a hard copy of a list prepared at that time. We also set up a folder for each as a dumping ground for any information we found about the projects.

The second part of the exercise is to put in place a process for managing new requests. Who can raise them? Where do they get recorded? Who evaluates the proposal? What information do you need to capture? We produced a relatively simple Concept Paper, and had a BA work with the initiator to capture the information. The proposal was vetted by the National Process Owner to decide if it would proceed.

We now had a fence around all the proposed project work.

How – How do we manage it?

Project Management Methodology

To implement any sort of consistency and efficiency you need a repeatable process. That should be supported by templates and techniques that everyone is familiar with. They should be able to refer to previous examples to better understand what is required. We set up a web based process supported by templates and examples.

It was not a revolutionary approach to project management. It was based on standard PMBOK practices. It did have elements that were unique to the company as all processes do, but there was nothing there that would surprise an experienced Project Manager. The online tool was implemented with training for staff in how to use the information. Mentoring also took place with each project team.

Tools

We implemented a number of tools ranging from standard spreadsheets to Microsoft Project. Naturally we implemented our own software which we developed in house. These were also supported by training and mentoring.

Other Processes

The web based Project Management Methodology also included a Software Package Selection Methodology.

At the time the CIO was implementing other policies and procedures including ITIL. We were able to use many of these to roll out standard ways of doing things. For example the ITIL Change Management process fitted neatly for implementation and testing. There were other standards created such as naming conventions in schedules and lists of authorities. As a need arose, we created the process or standard to fit.

When – When will it be done?

Prioritisation

We developed a process for prioritising projects and created an IT Steering Committee to set the priorities. The approach was that IT would do what the Business wanted, but the Business need to first agree to what they want. After a shaky start, the process is starting to work. The first few months resulted in a number of changes to priority until the committee realised how much wasted effort resulted from constant changes.

Another aspect that the IT Steering Committee is coming to grips with is that they must take into consideration the availability of Business resources. After constantly asking the question “who from the Business will work on this project?” and hearing the same names come up over and over, the message is starting to get through. To a certain extent, IT can recruit as many contractors to do the work as the Business are prepared to pay for. What you cannot buy is the business experience.

While the process is not perfect yet, it is getting better. The organisation is a long way from portfolio management but is starting down that path. In a few years priorities may be set in a more appropriate manner but where we are today means there is agreement between Business and IT as to what comes first.

Integrated Schedule

Once the priorities are agreed, we can put together a high level schedule to show where in the next 12 months projects are due to start and end. Everyone accepts that the estimates are guesses and in fact we have referred to it as the “Guesstimate Schedule”. It does however provide a high level planning tool for future workload. It also alerts all areas of the company as to when certain things are likely to occur and where resources may be required. Basically we are looking for start and end dates rather than details of particular activities within the project. For larger project we might list a few key milestones. At this stage, we are using Excel to show the projects against a monthly timeframe.

Where – Where is it up to?

Individual Schedules

Each project develops an individual schedule and the schedule is updated regularly. The individual schedule dates replace the ones in the integrated schedule. The individual schedule is developed during the planning stage of each project.

Tracking and Reporting

The obvious place to start is to initiate progress reports for projects. At first this was a very simple report:

Milestones in the last week and if completed
Milestones in the next week
Issues outstanding
New risks identified
Comments on progress

As time goes on we will become more sophisticated and include such things as expenditure, actions outstanding, resource issues etc. The plan is to start simple and gradually build the information.

The other part is more internal to the project. We have provided mechanisms for the team to manage its own information in terms of issues, risks, actions etc. It has taken some time to get teams to record and use this information to manage themselves. This is still a work in progress and is part of building the maturity of a PM team.

Who – Who will do it?

Resource Assignment

Managing who is assigned to what project can be done in Microsoft Project however it requires setting up resource pools, and is dependant on a granular approach to recording information. We found it easier to take a bigger picture view due to a relatively small and manageable number of resources. Using a simple Excel spreadsheet we were able to assign a percentage of each person to a project on a weekly basis. The approach is relatively simplistic but does show up bottlenecks. Each Project Manager nominates the percentage required, and over-allocations are negotiated.

Resource Alignment

This activity is to ensure we have the right people to do the job. The staring point was to create job descriptions for each person. They were then rated as to their capability to fulfil the role. By matching roles required in projects, we can see:

The project needs a certain role (e.g. Highly skilled BA)
The organisation has a number of BAs. Some of these have a “highly skilled” capability.
Can we assign one of these to the project?

If we consistently find we are short of a particular resource, we can look at:

Training for existing resources – which translates into a training plan

Recruitment of permanent or contract resources

Why – Why are we doing it?

Business Case

We are starting to move towards a formal business case for each project. This is a step away from the “volume method” or prioritisation. Whoever shouts loudest gets their project to the top of the list. For the first time projects can be rated on things like costs and benefits. The “riskiness” of undertaking a number of projects can be compared. How they contribute to strategic direction can be viewed.

This method is a step up in maturity for the organisation and will take time to put in place. A full business case for each of the 150 projects will take years to complete. What we want to do is look at a shortlist of maybe 10 projects and do a business case for each. For smaller projects – less than 3 months – it may be a simple cost benefit analysis. For big projects it might be a significant document. Scalability is important in many aspects of the changes we are putting in place. Rarely does one size fit all.

We also undertake a Phase Zero study which looks at the feasibility of the project. It answers questions such as:

Does everyone have a consistent view of the project?
What is the scope? What is out of scope?
Do we have resources to commit?
Where are the stakeholders positioned on this project?
Are there any differences of opinion we need to resolve before we start?
What are the things that can cause this project to be unsuccessful, and how are we dealing with them?

Benefit Realisation

There is no point in stating benefits if the person making the claim knows that once stated, the benefit will never need to be delivered. To give credibility to benefits they must be audited for delivery. This is another step up in maturity. Once in place, it will make the business case a much more credible document.

Portfolio Management

Yet another step up the maturity will be to introduce Portfolio Management. This is some way down the track. The organisation is just not ready for it and it is really not understood in enough detail to be accepted. Someone once said a leader is one step ahead of the crowd, not over the horizon. People need to be taken on a journey to build a more mature company.

Conclusion

It was not until I put this map in front of people that they started to see how a number of concurrent activities fitted together. The actual map I used had different colours for different boxes. Green were things that are in place, yellow in progress, and red not started.

What I found from this exercise was that although I had a big picture in my own mind, I needed to find a visual way to communicate that to a broader audience. I had activities happening all over the organisation but people did not see how it all fitted together. Only when I was able to show them one piece of paper could they see where their piece of the jigsaw fitted.

A project infrastructure will not happen in a week or a month. In this case we are eight months into the process and probably two thirds of the way through. It can however happen in a year or so and no matter how bad the starting position, if you have a big picture to work to, you can take the organisation to a new level of project management professionalism.