Project Perfect - Project Management

Where to start?

Recently I have been working on a program of work where there are about 30 to 40 projects up and running and now they decide they need a program office. How do you retro fit a program office to projects that area already well down a path - albeit a path they should not be going down.

There are some with no scope defined. There are different reporting techniques. There is no centralised risk or issue register. Budget funding is a mix of operational and capital budgets and there are no gates to be negotiated for non-capital projects.

Here is where we decided to start.

Firstly we introduced a standard weekly report to get people focused on at least reviewing their status and listing significant events. These included issues, resource problems, new risks, and some comments on progress.

Secondly we put in place a risk and issue register using our Project Administrator software. We forced people to put in place action items against risks and issues to ensure they were being addressed. These are monitored on a weekly basis so people are becoming used to achieving action dates. We collected roles and responsibilities and logged them in Project Administrator.

The next step is to work with each team to define scope and deliverables. From that can come a schedule. Once we have the schedule we can identify resource needs and budgets. We will also be working with each team to do a risk assessment. We will use Project Administrator for Change Control.

It is a bit like trying to board a moving train. Some projects are well managed, and others not so well. It is not until we get on board we can find out. Fortunately, with Project Administrator we have a ready made repository to store information. It is forcing a common approach on the teams, and we are now starting to get some control back at the central level.

New White Paper on Costing Internal Resources

Our white paper this week deals with how to treat internal resources from a financial, or project costing point of view. This is always a hard one for organisations. Do you cost, or not cost internal resources to the project.. Read the paper at http://www.projectperfect.com.au/info_internal_project_resources.php

Developing a Test Plan

In a previous white paper we covered the way in which you could develop a test strategy. http://www.projectperfect.com.au/info_test_strategy.php The second part of our white paper on testing covers the development of a test plan. http://www.projectperfect.com.au/info_test_plan.php It has some useful checklists to help you put together a comprehensive applications test plan.

Deadlines

I was reminded recently of a trap that a Project Office can fall in to. This particular Project Office had a deadline of Friday for reports on all projects. There were about 200 to 300 projects so Friday for the Office was paperwork day. At 5:00 the email was jammed with people reporting.
It sounds obvious but if you have weekly reports, stagger them. There is nothing magical about Friday. Have some reports with a deadline of Monday, some Tuesday etcetra. That way it spreads the workload for the office.
An added benefit is that a person receiving reports on a number of projects is more likely to read them if they receive them in a drip feed rather than a flood.
Just something to think about to make your life easier.

An IT Project Concept

The ongoing discussion about IT projects that failed because the work was not correctly estimated got me thinking about why you can estimate work reasonably accurately in construction and engineering projects, and not so accurately in IT projects.
I was listening to someone recently who said that in terms of maturity, the engineering field was decades, if not centuries ahead of IT. Engineering principles have been known for hundreds of years and the maths behind it are well established. If you want to build a road, there are precise formula that can tell you the materials and labour required.
I started thinking about a two dimensional model to explain it. The x axis represented available metrics. The y axis represented ability to translate concept to quantifiable form. For example, to be able to take a bridge and break it down to components that could be sized accurately. In IT it is the ability to take a conceptual business solution and break it down into chunks of code.
A construction or engineering project is usually in the quadrant positive metrics and positive translation. An IT project however is probably in negative metrics and negative translation. There are few definitive metrics for IT projects and translation from concept to physical components is not an easy task.
Another factor in IT projects is the time it takes to move from concept to physical components. Often more than half the time is gone before the physical components are identified. In engineering type projects, because the components have probably been used before in other designs, the detail emerges much earlier.
I am not sure this adds much to the understanding of why projects are over time and over budget but it is an interesting concept to explore, and perhaps someone else has a view that could add to the discussion.

Kids Project Management

One of the issues we have pushed for the last few years is project management to be taught in schools. We are not talking about a PMP but rather some basic principles. Things like breaking work down into chunks and setting milestones. Forward planning.
One of our regular members is trying to make it happen in South Africa. She is working with other parents and teachers to try and implement some basic training in project management. We are moving from the concept into the planning phase and would love to hear from anyone who has some ideas on how you actually structure a training program.

Service Delivery Management White Paper

For anyone looking for a concise explanation of what service delivery management is about, this is an excellent article. Sandeep Mehta explains the role of a Service Delivery Manager and leaves us with a diagram that sums it all up.