Notes for Project Boards > Start up ambiguity

There is this specific situation where you do know that a project should start but there is not yet a clear assignment. This could cause the startup to stagnate. If there is not a clear assignment the project cannot start. But if the project does not start a clear assignment will not be established. This is probably caused by a misunderstanding about project management.

Project management is introduced where normal processes and procedures cannot handle the request due to the lack of control and management to meet the complexity of that request. In fact the request is very different from a normal requests that can be handled by the process. So in that case one cannot say that the request does not meet the entry criteria for the process, as this is the reason to give extra (project) management attention to the request.

One of the first steps in this ambiguous situation is for the Executive to find and talk to the Project Manager. They will discuss that the scope for the project is not yet clear and who is to be involved to make it clear. This means that specialists are asked to identify the Project Deliverable. I would like to call this the 'picture of the future' as it shows (only) what is available by the end of the project, not (yet) what needs to be done for that nor how it is done. Spend appropriate time to 'take this picture'.

Notes for Project Boards > Value for money

Last time I promised to come back on the subject 'Money'. Money is one of the criteria used to control a project. In many cases however the information is about the budget, what was spend en what is left. But what do you know when you have this information? Well you have a reasonable view on the project status as is. But it is 'looking back' on what has happened. Is is usefull? Yes. Is it all you need to know? No!

As a member of the Project Board you will want to know if the project will be succesfull. You will want to know if the project will achieve its targets within the criteria you agreed on with our Project Manager. You will want to know if the product delivered sofar are value for money. You will want to know if the work, still to be done, will be achived within time and budget. Will the remaining product be produced against the agreed budget?

Therefor it is good to know a budget for a project, but wise to know what cost and value is connected to every product the project will produce. So do not agree to a budget based on hours times cost but have an overview of price per deliverables. Every deliverable has it's price and a value. When you spend money on a deliverable is should bring you some value. And if possible this value should be worth the money you spent on it.

So the project budget should be the sum of all product prices and you should have your Project Manager analyze the value you earned sofar and expect to earn with the coming products. With this method it cannot happen that you spent 80% of your budget and achieve 20% of your target. You might think you are on track (80%) but be aware you're having problems (only 20%).

Notes for Project Boards > The Money

So we agreed that money might be an interesting criterion to keep track of to see if a project is on target. You might say this is the easiest one, maybe besides the planning. Is the project ready in time and on (or below) budget. But what is the case?

Projects tend to start with a limited amount of information. This is evident. Projects start because the existing organization is not capable of doing the thing that is expected to be done. If that was the case we would not have started a project. See a posting some while ago. So in the beginning the budget is a bit fuzzy.

During (starting-up and initiating) a project, things become clearer. No problem so far. Get used to that being a normal situation within a project. And even on the go, information and circumstances can change so budget will need adjustments. But at a point in time your Project Manager will say: 'This is it. This is the money I need'. At that point in time you should wonder: 'What is he talking about?'

In many (not all) cases the money is based on spending for labor and purchases. How many hours will the team members spend on the project and what will we buy during the project. Sounds fine, doesn't it? Well, ok it is reasonably fine but not complete. You should expect an insight in the cost of the deliverables. The cost of a project product is a sum of costs of all separate products that will add up to this one final project product.

Do not settle for an overview of hours, cost per hour and a total. Ask for price per product. I will come back on this.

Notes for Project Boards > Freedom to move

When you have a project team and a Project Manager to manage this team, you would like to spend just enough time on managing your project. A widely used approach to achieve this is criteria and tolerances. Critical Success (or failure) Factors (CSF's) and Key Performance Indicators (KPI's). This sounds familiar doesn't it? Kaplan and Norton? Balanced Scorecard?

When you have a project, you in fact have a temporary organization with directors (you), management (PM) and organization (project team). And for this organization you will need some indicators to measure the performance of this organization. Will it work towards the desired result? And does it achieve this result within defined limits? A classic set of criteria consists of money, organization, quality, information and time. But it is up to you to drop or add any criterion you like.

Better is it not to just do what you like but what is good for your organization. Doing better what you already do very well is not useful. To improve what needs to be improved is much better. Therefor one can do a SWOT analyses on your organization and the project team. Where are the strength and weaknesses? Where are the opportunities and threads? This will help you understand what criteria you should pay attention to as they could go wrong and where you should not spend to much time on as your organization is very strong in that area.

A further nuance can be given through tolerances. Bear in mind that you can have different tolerances on different criteria and between positive and negative deflection. The interesting question is: 'What are good tolerances to work with?' I will come back on this n a next posting.

Notes for Project Boards > The Senior Supplier

'Well, if you know what you want, I will make it'. Is it as simple as that? A good supplier will not just make what a Senior User wants but take responsibility for that product. It is not only the Senior User who has requirements. There are requirements that the Senior Supplier should, or better, is obliged to consider when making the project product.

One has to bear in mind that the Senior User (in many cases) is not the specialist when it comes to the product. A pilot is not the specialist when it comes to plane construction. He will know how to fly one and might understand how it is constructed but being the specialist requires other competencies. Those competencies are to be expected from or at least represented by the supplier of the plane. In many cases those requirements are applied by law, regulation, good practices and so on.

In a Project Board the Senior Supplier should represent those requirements and when needed explain the consequences of those requirements. So both Senior User and Senior Supplier represent interests, requirements, restrictions of different kinds and origins that sometimes conflict with each other. And, as stated before, these should be discussed in the Project Board.

Notes for Project Boards > The Senior User

Who should be the Senior User. An interesting question that should be addressed very carefully. One can also wonder if the Project Manager is the one to decide on this question. I think not.

Senior Management or a program gives a mandate to an Executive. In both cases it is expected that it is clear who will use the final project product. This can range from a minor department in the organization up to all employees and even external parties like customers and suppliers. Users are important stakeholders of the final project product as in many cases they are expected to achieve the profit mentioned in the business case. It is therefor important that they are represented in the Project Board where discussions about what is produced and what is needed can be settled. The Senior User is the representative of all users. This can also be a department the will manage the product after handover.

To be able to take that representing role the Senior User should be given the right authority. He should be able to negotiate on the behalf of the users meaning that he should guard the requirements and he should be able to accept changes in the organization or processes to achieve the agreed profit.

In many cases it is not clear who is capable and in the position to take that role. It is therefor important that a Project Board takes time to seek and find the best suited functionary and arrange all needed mandates for him to take the role of Senior User. The Senior User role can be taken by more than one functionary. Make sure their responsibilities do not overlap. Keep the Project Board as small as possible.

Notes for Project Boards > Programs

I would now like to consider how a Project Board relates to a program. But before we do that we should consider the differences between a project and a program. As there are many books written about this subject one can understand that I will not fully go into this in one posting.

However, the statement that 'projects cost money while programs save money' helped me to get the difference a bit more clear. This is a bit short. Another way to look at it is the difference in attention area. Where programs tend to look for a bigger picture, a project focusses on a smaller area. This could be organization wide against departmental. Maybe this is more useful in your situation.

But what should be clear is that a project provides a part of the solution a program is aiming for. This is different from having a project portfolio and the management of it. The latter has more to do with setting priorities. Where do we spend the limited amount of money? Portfolio management can be a part of program management bit is just one of the attention areas.

All projects, also the ones initiated by a program should have Project Boards. A program will have several Project Boards with their own mandates. This will give project management team room to operate at their own pace and their own responsibility. A Project Board will be much more involved with the projects objective then a Program Board.

The Project Board will take its own role and responsibility and will respond to the Program Manager instead of to line management. And a Project Board should not leave this up to the Project manager. For what reason are you a Project Board? If it turns out that it is perfectly possible for a Project Manager to respond to a Program Manager one should consider if there is a program at all or if it is just a big project. If this seems to be the case a Project Board can, no should, take immediate action. Functional organization is one of the responsibilities of a Project Board.