Home > Articles
The over-large project board discussed in a previous Thoughts — Project Governance, Less is More was brought about, in part at least, by confusing the different roles of key stakeholders. A common problem on large projects is to give equal authority to advisers and decision-makers.
On large projects with many, diverse, user groups there is a need to consult widely with many subject matter experts to ensure that there are no gaps in the project requirements and all needs have been understood. Once understood not all the stated needs may be accepted into the scope of the project board. That is the responsibility of the project owner and a small, selected team authorised to define the scope and budget for the project. That group, essentially the project board, will be accountable for delivering the project scope once the budget holder’s senior management team has approved the project details. For large or strategic projects, it will often require board or executive management team approval.
Many user groups will believe that they have a say in making the decision as to what should be in scope. In reality, they need consulting and their needs considered alongside those of many other interested parties. However, there will need to be a decision that balances conflicting requirements between groups. As a result, such subject matter experts can only advise as they have vested interests and may not have the full strategic picture. To facilitate those discussions a committee of senior users may be appropriate to explore the wider picture and ensure that it is complete even if issues of scope remain unresolved.
It may even be a hierarchy of committees so that individual communities of users can agree their needs and have them represented in a wider forum that advises the decision making body on the desired scope and priorities. That senior advisory body should usually be chaired by the senior user from the project board so that he or she is conversant with the advice and can represent in a separate decision making body.
Much is made of the need for responsibility and accountability on projects. However, there are limits on how widely they can be distributed. On many projects, large ones especially, there is a confusion between project responsibility and stakeholder management.
On one very large project I know of the senior responsible owner was concerned about making stakeholders accountable. As a result he insisted on them being on the Project Board and party to the project decision making. The result was the largest project board with which I have ever worked; there were around 24 people on that board. His thinking was that all members would then be equally accountable; unfortunately, he misunderstood the dynamics of groups.
The result was that no one, no one was actually accountable. Jerry Harvey, the American psychologist, noticed that groups often take decisions that are at odds with decisions they would take as individuals. Even to the extent that as a group they would take decisions they would personally regard as perverse. Harvey noted that the groups takes strange decisions because individuals know they can avoid personal responsibility for the groups actions. He called this behaviour the “Abilene Paradox”; he compared it to a family that chose to go to Abilene for a vacation even though individually no one had any desire to do so and knowing the journey would be unpleasant.
The other problem with such a large project board was that it became a talking shop and was slow to take decisions at all. With over twenty people travelling from all over the country it was also inordinately expensive so it was hardly surprising that the project was on its fifth project director and running over a year late. It was eventually delivered after a further replanning and with a reduced scope.
For the sake of consistency, we need to understand what we mean by a project. Project managers who have been involved with projects for a while usually have a clear view. Although the definition of a project may seem obvious to experienced projects managers it is often not so clear to new project managers or managers with only business as usual or operational experience.
Many definitions of a project are written in rather worthy and pretentious terms. For all practical purposes a project has clear set of characteristics, projects:
A project may be a one-off or it may be part of a series of linked projects or programme of work to deliver strategic outcomes. In such cases, the allocation of resources and project organisation may not appear temporary. Good project discipline requires formal closure of a project when it has delivered its objectives (or abandoned for whatever reason); then a new project properly initiated with its own clear scope and constraints.
Whatever the tool good craftsmen achieve much more with them than the average user. They demonstrate a facility with the tool of which most users can only dream. The same is true of project managers and their use of project tools provided by methodologies such as PRINCE 2.
All too often organisations train staff in the use of PRINCE or other methodologies and expect them to be equipped to run projects. Often such people have never worked on a project prior to such training and as a result do not really understand what is involved. I faced such a situation when I took over a major government change programme.
I inherited more than a dozen “project managers” each with responsibility for major workstreams within the programme. During initial discussions with each individual it was clear that they had no idea how to plan or scope a project. They all had PRINCE certificates so were aware of the documents required by the methodology but with no appreciation how to create or use them as a project manager. In reality they were senior subject matter experts (SME) seconded from the frontline service. In methodology terms they were equipped to be senior user on a project board rather than the project manager.
They had, very unfairly, been put in an impossible situation so before I could get on with managing the programme I had to grow them from a low level of project management skills. I really needed to get to grips with a critical £100+ million programme that was already behind schedule. Before I could, I had to create a serious of project management training workshops to give my team some skills and knowledge of basic project management. I had to cover such things as basic project planning, work breakdown, budgeting and such matters as dependencies, risk identification and mitigation, and project software. All this had to happen even before I was able to explain how to control a project once it was up and running.
The lesson is that staff who are to manage a project for the first time need more than simply training in a methodology such as PRINCE. Before that training they should have some experience of projects, perhaps in the case of my “project managers” they should have spent time on a project as a subject matter expert, and thereby developed some feeling for the dynamics and characteristics of projects. This would then have allowed them to put the methodology into a real world context. Instead it was just a strange bureaucratic process they believed to be “project management”.
It is your briefcase, stuffed with work you have brought home to do over the weekend. You knew in your heart when you packed it that you would not get it done. But still you brought it all home even though you have a busy weekend of family commitments. Why, oh Why?
Many years ago I had a boss, Mike Fitzsimons, who taught me a valuable lesson, one I practiced until recently. He pointed out that although we have good intentions when we take a bag of work home at the weekend we rarely get it done. If we do it is often at the cost of domestic harmony. The description of a case of work throbbing gently in the corner is his. His alternative approach was to get into the office early on a Saturday and clear the work he would otherwise have taken home. Generally he had it done by coffee time and was back at home well in time for lunch with the rest of the weekend clear in front of him.
At the time we usually worked away during the week on client sites so we did much of our work in hotel rooms; there was not much else to do. It was in the days before e-mail so there was always administrative stuff to do when we did make it back to the office for a few hours. By going in and clearing the administrative backlog he could relax knowing it was not building up.
I started doing the same and spending just an hour or two in the office early on Saturday rather than taking a bag of work home. It had the advantage that my boss and I were also able to catch up, share information and plan our response to any new opportunities or challenges. By 11am I was done and the rest of the weekend was my own to enjoy with the family without guilt.
It is important to find a way of separating work and home life. If one does not, one may wake up one day and find there is only work. And work is uncertain in these times of austerity.
Methodologies, such as PRINCE 2, are widely touted as key to successful project management. If that is true why do so many projects supposedly managed using such tools still come in late, over budget and deliver limited benefits? This is brought to the fore by the recent scaling back of the multi-billion pound National Programme for Information Technology that was supposed to be the future administrative underpinning of the United Kingdom’s national Health Service.
Most experienced project managers can tell tales of projects run strictly to PRINCE framework that never got delivered or were late and over budget. A classic example from my own experience was for a new telecommunications company. The programme was running late and the programme manager was replaced by an experienced PRINCE practitioner. He started by imposing PRINCE disciplines with formal recording and reporting. Unfortunately the projects still continued to slip.
He was advised that he was not catching up with the programme. It was moving away from him faster than he could catch it using formal methods; he just could not get the necessary decisions taken quickly enough. Bear in mind this was a start-up company with all the energy and lack of formal management that goes with it. The attitude throughout the company was “just do it” so formal change control and other decision making processes just did not work.
After six weeks he accepted the reality that it was not the environment for him and resigned. I picked the work up. I liberated the project teams from all but the most essential paperwork and gave them the responsibility to take decision as long as they kept everyone informed. Realising that formal governance was not working I adopted an approach of telling senior management what we would do unless they told me not to. No response was approval and I would go ahead as planned. It was an extreme form of management by exception but it fitted with the culture of the organisation. We achieved sign-off on schedule. It is a high-risk approach because failure will fall squarely on the programme director or manager; sometimes one has to stand up and be counted.