Project Infrastructure	First published Oct 06
Neville Turbit - Project Perfect	Rating
(Download pdf version)

Overview

I was at a barbeque recently when someone asked me what I did for a living. The response was Project Management which usually results in a question like

“Buildings and things?”

or

“One of those IT types. Tell me why do so many projects fail?”

At the time another term came into my head. It is one I had never thought of before although I am sure someone has used it. What I really do is “Project Infrastructure”. Perhaps it was the red wine that stimulated the creative streak but it suddenly hit me that what I do is help organisations put in place a project infrastructure.

Analogy

I have been working with a large telco who is looking at their business cycle from quote, to delivery of the first bill. Their focus is in the following areas.

Sound familiar? These areas are exactly the same ones that an organisation works on when trying to make their project management more efficient.

Definition

Here is how I define Project Infrastructure.

Project Infrastructure refers to the organisational structure, processes, tools, techniques and training an organisation puts in place to make projects more successful.

• Organisational Structure – Organisational structure including such support mechanisms as project management office, project recruiting function, financial monitoring area etc. It also covers lines of communication and escalation.
• Processes – Typically methodologies, checklists and guidelines
• Tools – Software and templates
• Techniques – Repeatable processes such as kick off meetings, PIRs, analysis techniques, etc.
• Training – Formal and informal training and reference documentation

Reviewing Project Infrastructure

Most people have never thought of having a project infrastructure. They might think of having methodologies and templates, but not taken a holistic view of their project infrastructure. To go back to our analogy with the telco, if the review of the business area only looks at automation, or only looks at roles and responsibilities it is going to give an incomplete result. A more integrated approach is not only required. It is absolutely essential for success.

Project infrastructure is about reviewing the whole environment and finding out how to put in place an environment that will work in an integrated manner to support projects. Looking more closely at each area, we can see the following.

Organisational Structure

Structure refers to how a team is organised to be most effective. Understanding what a team is best left to do is a good starting point. For example, is it an effective use of time and effort for a project manager to update resources requirement projections and recruit resources? Perhaps it is more effective for a project coordinator working across several projects to undertake this task. Perhaps a recruitment area could shortlist project resources.

Another area might be project financials. Is there justification for a central project financial area? One quick test is to say what would be the cost of all the project managers tracking financials and what would be the cost of having a single project financial analyst function. I have even seen a small organisation combine both resource and financial roles into one person.

Processes

To take one of my hobby horses, a project management process is not a collection of templates. Templates are the output of processes. If you are doing a risk assessment, you should not start off with a template and fill it out. You start off by understanding what is involved in carrying out a risk assessment. You understand the techniques to generate a list of risks. You understand who should be involved. You understand rating risks for impact and probability. After you put all this together into a process, you end up with information that finds its way into a template.

I had to make an insurance claim some time ago. I was given a multi page claim form by the insurance company. I struggled to fill it in knowing that any blank field would likely cause a delay in payment. The company had to come back to me to clarify some details that I had entered on the form without understanding the intent. This was a “template driven” process. It would have been far more effective if I had understood what they needed and then I would have known how to find that information and put it on paper. That would have been a “process driven” process.

An organisation needs to put in place processes in order to bring some consistency to the way in which projects are managed. There will always be a need to tailor the process but the aim of the process is to ensure there is a minimum “reinventing of the wheel”. It also means the organisation has a clear understanding of what is happening because it has happened that way on previous projects. Projects don’t exist in a fog.

Tools

I have seen organisations with a number of tools to do the same job. Almost certainly this will result in problems. For example, one organisation used both Artemis and Microsoft Project to create schedules. Those with Project could not integrate with the Artemis schedules. They didn’t even have access to Artemis. There were lots of lists of dependencies maintained manually in spreadsheets.

Having a consistent set of tools is fundamental to the creation of a project infrastructure. Tools may include

• Scheduling tools
• Risk and issue management tools
• Financial management tools
• Document management tools
• Action Item management tools
• Databases for recording anything from benefits, to progress reporting, to resources

Techniques

Techniques are the common, reusable process that an organisation develops, or that an organisation subscribes to. For example, an organisation may use JAD sessions. There are a number of techniques around JAD that need to be applies in a consistent way. People should be trained to apply the techniques, and participants will become familiar with the techniques. It makes life much easier if people can quickly slot into an environment because they have undertaken a similar activity previously.

One particular area where techniques are important is in the development of requirements. It should not be up to the project manager or business analyst as to what techniques they use to gather requirements. The organisation should make a decision as to the technique they will use and every project uses the same techniques.

I have seen many organisations use a range of techniques such as UML, Data Flow diagrams, Functional Definition etc. to document system requirements. Each new project required a learning curve for participants where they had to become familiar with a new technique. Another factor was where people preferred another technique so you end up with resistance, or a blended technique. Typically it results in a new set of problems.

Training

Communication does not take place by osmosis. There needs to be a training program in place to communicate the way in which projects should be undertaken. Training will likely range from classroom to CBT (Computer Based Training) to “one on one” training for new project managers.

The training should not end at project managers. It is important that project participants also receive training so they can understand how the project will be managed and what they are expected to contribute.

How to start building a Project Infrastructure

It is unlikely you will start with a blank slate. If you are building a project infrastructure, you will almost certainly have some things in place. There may be templates, processes, techniques and documentation already in existence – if not in use. There are bound to be a few tools – probably some of them home grown.

The starting point should be to carry out an audit of what already exists. Look at the categories identified above, and try to collect anything that fits into a category. Also do a quick assessment of the potential usability of the item.

For example, in one company I looked at, they had an old project management intranet site. I was told “There is lots of good stuff there.” When I was able to resurrect the site, most of the links were broken, and much of the documentation attached to the site no longer existed. It did however provide a starting point. By talking to people who had been around long enough to have used the site, I was able to dig out a number of documents and screen prints from the site when it was in existence.

Define the Scope

Just like any project, we need to define the scope. The edges of a project infrastructure can be blurred unless they are defined. For example, where does the project infrastructure take you in terms of financial management? Where does the normal company financial management start in relation to projects? Does the project infrastructure include a skills register, or is that part of the HR function? Who allocates PCs to project teams? Is this part of a project infrastructure or is it part of your normal facilities management? Is space allocation for teams part of your infrastructure?

Project Process Modeling

Once you have the scope identified, it comes down to a business process Modeling exercise. Take a new project, and navigate it through the organisation to completion. It is likely there will be multiple paths. For example, you may decide that there is a different path for a small project than for a large project. There may be different steps for projects requiring capital approvals.

The purpose of this will be to understand what the optimal infrastructure is that you need to put in place. The project process model will highlight where project infrastructure is required. For example, one step in the process will be to define scope. When taking a project infrastructure view this may mean you need one or more of the following:

• Guidelines for running a scoping workshop
• A template to record scope
• Examples of previous scope documents
• Training on how to create a scope statement
• Guidelines to identify the various components of scope (Outcome, internal and external deliverables, objectives etc.)
• Checklist of common deliverables (Training Materials, Product Documents, Operations Manuals etc.)

By taking each step of the process, and asking “What infrastructure would make this more efficient?” a model of the infrastructure can be built.

Standing Infrastructure

The project view is not the only view. In order to undertake projects, there is also a standing infrastructure. This is analogous to having a HR department to recruit staff for a line of business. One cannot exist without the other. The standing infrastructure will include things like:

• Knowledge management
• Skills optimisation
• Resource Management
• Training
• QA
• Reporting

The projects will draw on the standing infrastructure in order to complete their work. Some will be visible when you look at your project process model, however not all will be visible. A view needs to be take from a Project Management Office perspective to understand what other standing infrastructure needs to be included.

Gap Analysis

Given we now have a much clearer view of what is required, we can compare this with what already exists. What we will see will be:

• Existing materials that fit the proposed project infrastructure
• Existing material that does not fit but could be reworked to fit
• Existing material that does not fit, and will never fit
• Gaps
• Duplication of materials (e.g. In one organisation I found 4 templates to request seed funding for a project. They were all in use).

Implementing the Infrastructure

It is likely there will be entrenched positions when it comes to giving up the old. Some people will use approach A and see no reason to use approach B. Some will use B and see no reason to use A.. If there are valid reasons for only using one approach, then it will need to be enforced. You will need the support of senior management to make it happen.

Before you start the process, there should be activities around selling the concept of a project infrastructure. There will be benefits to the company, but will there be benefits to individuals? Here are some suggestions to help acceptance.

Working Teams

Form working teams to develop parts of the project infrastructure. For example, you might have a “Project Initiation Team” who put together the entire infrastructure to establish a project. They will need to work closely with other teams to ensure integration. Clearly defined scope, and a signoff process is important if you don’t want to end up with a patchwork quilt. Another group might focus on Tools; another on Risk Management. If anything looks too controversial, then it is probably best taken out of a workshop and managed by Project Infrastructure implementers.

Look at Individual Motivations

Think what might motivate individuals and find benefits that will appeal to each person. For example:

• A “tidy” person will see appeal in having a clear concise path to follow with a consistent look and feel to the entire infrastructure.
• A “busy” person will focus on the efficiency of a clear process
• A “less experienced” person will be motivated by having training and a clear path to follow

Recognise Contributions

If you use a template someone has developed, recognise them for the effort. In the version control section make sure the person who developed the template is identified. Recognition will encourage ownership.

Single Source of Truth

How often have we all seen multiple versions of documents? Which one should you use? Start out be making a single source of documents that is under tight control. Anyone can read, but only a select few can update – and then in a controlled way. If a document management system is available, it is a good option.

Also consider making the documents available through the intranet if it exists. If people get used to going to the intranet to find master documents, it will put a control over morphing versions. Combined with a document management system where the link is probably cryptic, this can be a good way of managing documents. Converting reference documents to PDF is also useful.

As an interim measure, I once created a web page with a listing of templates with hyperlinks. I put this in a central location on the LAN and sent everyone a link to the page. Rather than people wandering through directories looking for the most recent version, they opened the browser page from their desktop and clicked through to the version we wanted them to use.

It is Never Finished

There is always room for improvement. Make sure you put in place review mechanisms. Many organisations have a project management group who look at how project management can be improved, or provide training to other PMs. It is good to have a feedback forum to look at improvements to the project infrastructure.

Ownership

Make sure it is clear who owns the infrastructure, and who is responsible for authorising changes. If the ground rules are set prior to the infrastructure being built, it will make it a lot easier to reach decisions.

Project Infrastructure and Governance

AS 8000 defines Corporate Governance as “The system by which Entities are directed and controlled”. The following diagram shows the scope of governance.

To date, 47 people have rated this article. The average rating is 4.19 - Add your rating. Just select a rating and click the button. No other information required. Only one rating per person is allowed.

Project Infrastructure 1 2 3 4 5

Return to the top