From Classroom to board room

If you’ve ever wondered why you took a PM certification, Geoff Filbey has some practical answers

By Geoff Filbey, PM-Partners group

October 2010.

Most of us have been there. Somebody somewhere, usually our boss, hints subtlety, or not so subtlety that we need to put some acronyms next to our auto signature. We need to get some sort of formal PM accreditation. It is time. So off we go to a PRINCE2 or PMI certification course, apprehensively.

We study hard, when the instructor loses us we ask questions, we suffer acute test anxiety and then most of us pass (eventually) with great relief. On go the acronyms, up goes the pay (possibly), and off we go on our journey.

Once the business of the three to four hour exam is over, once we have time to reflect, the questions that spring to mind are:

1. How practical is the knowledge I have acquired?

2. Does any of the ‘theory’ actually work in the real world?

Many of us have been here as well: some organization, somewhere, has decided that it is high time for a good old fashion ‘business transformation project’ of the technical kind. It is time to embrace cutting edge technology, remove old kit, migrate sensitive data, train highly specialized knowledge to IT staff, etc. Before the project even formally begins the emails start flying. Nervous stakeholders are asking a dizzying array of questions. Risk, schedule, scope, strategy, governance and key technological design questions are being talked about between an ever-changing group of individuals with no overarching structure or strategy – let alone formal documentation.

From the outside it looks like a classic Muppet Show episode. You would have a good laugh as well, but you are not on the outside. You are right at the epicentre; you are the project manager. You need to find a way to sort this out.

Once we have a second to reflect, we ask ourselves:

How on earth am I going to get all of these people to sing and dance together? How can I bring order to this chaos and get this project moving in the right direction? How can I get these various stakeholders to start discussion scope, schedule, risk and technological options in a controlled, measurable and meaningful way?

Ironically, the answer is found in the first questions. Remember them? They get asked after you pass a certification exam:

• How practical is the knowledge I have acquired?
• Does any of the ‘theory’ actually work in the real world?

I was faced with this, not that long ago. I was hired to manage a large-scale project for an investment banking company. The project called for a complete transformation of IT assets and processes through virtualisation.

Our objective was as follows:

Our Business Case Stated:

‘Objectives and High Level Strategy: Through a process of virtualising logical application and service platforms, the project objective was to build a service oriented utility infrastructure model to dramatically increase IT asset utilisation. Additionally, virtualising physical machines allows for the reduction of the IT footprint within the datacentre, thus releasing space for future expansion and avoiding the cost of either sourcing third party datacentre space, or expanding its own. Power consumption is also significantly reduced.’

Unfortunately, when one undertakes a massive virtualisation project, stakeholder opinion starts to differ regarding methodology, strategy, hardware options, etc. And that is when the emails start to fly. So, by using an autocratic, directing approach – you’ll find that one in the PMI’s PMBOK – I coerced our team to agree to a moratorium on all email questions about the project until after the Project Kick Off.

That did two things:

1. It stopped a lot of potentially ‘he said, she said’ conflicts that inevitably arise when scope, schedule, cost, strategy et al are not, discussed in a controlled way.

2. It put all the attention on me. (The team is thinking, ‘OK, we can’t talk. When is he having the meeting, what are we goingmto discuss, when are we going to get to work?’)

Now, I knew I had one opportunity to get this project moving in the right direction. More than any other project I had managed

in the past; I needed to get the Kick Off meeting right. Back in the classroom, a PMI certification instructor might ask you about where my project was in its life cycle at this exact moment in time by using a typically ambiguous PMI style question such as this.

Geoff’s Project is where in the project life cycle?

a. Completed. (Develop Project Charter, Identify Stakeholders, and Plan Communications Processes)

b. In the Initiation Process Group

c. Preparing to develop the WBS

d. Don’t know, don’t care. I don’t have to think like that anymore since I passed the test and there are far more pressing issues at this exact moment.

Answer Hint: Franklin (blank) Roosevelt

If I was taking my PRINCE2 exam again, I could turn to page 31 (you gotta love open book tests) and read all about SU2 – Appointing a Project Management Team. But it looks bad if you run a ‘Kick Off’ meeting with Managing Successful Projects with PRINCE2 on your lap. I had more practical things to worry about. What I needed firstly was to list all the things we could reasonably achieve in a Project Kick Off meeting given the following immediate issues:

1. The project had no formal governance

2. Project communication was scattered and undocumented

3. The project had no defined life-cycle or being made ad hoc and on email

5. Stakeholders were not identified fully

6. Stakeholder expectations needed recalibration

7. Stakeholders were chomping at the bit with: ‘how much will this cost!!!??’; and ‘how much time will this take!!!??’ questions without understanding the consequences of creating unrealistic and unachievable budgets and schedules.

Given these issues, I asked the immediate team, ‘What should the main objectives form the kick off meeting be? How can PMI and or PRINCE2 help in a practical way?’

Here is what we came up with:

1. Establish Project Governance

Create a Project Board using PRINCE2. The roles and responsibilities of the Board were copied directly from the PRINCE2 handbook (don’t worry I gave them credit) into a PMI style Communications Plan.

2. Establish Project Controls

The PRINCE2 concept of budget and schedule tolerances, assigning levels of decision making and confirming stage boundaries work like a charm in these situations.

3. Create a logical project life-cycle through phases

PMI says Phases; PRINCE2 says they are not Phases but Stages. My unruly stakeholders don’t know much about them at this point either way. In their heads, they are trying to imagine every component of this very complex and long-term project all at once with no boundaries. Discussions about design, hard ware procurement, configuration, migration etc. are tumbling over each other with no logical sequence. They are getting themselves into a right old state. It is time to give this project some shape. Using a collaborative team approach, I held a brainstorming session to put the key project objectives into logical phases with clear deliverables at the end of each phase.

4. Get the team to understand and appreciate the logical sequence of events that must occur before Scope, Schedule and then Costs are base lined.

PMI shines here. The good people in Pennsylvania really understand how requirements must be thought out carefully and documented meticulously. So, my objective for the kick-off was to get the stakeholders to understand that arriving at an accurate budget and schedule is a process, which includes the following events.

a. Complete Objective 3 at a high level.

b. Phase 1 should be Create Detailed Design.

c. The scope of the project will be determined and base-lined in Phase 1.

d. Specific design sessions will be held on specific technical components of the project.

e. Each technical design session will have an objective, agenda and minutes, which will be, distributed post meeting.

f. The outputs of (e) will serve as the primary input into creating Project Scope Statement, which will articulate the scope of the project and how it meets Business Case Objectives.

g. Near term objectives will be planned and estimated in great detail. Long-term objectives will be planned at a higher level and then planned in more detail as the project moves through its life cycle.

h. Using this approach, we will create Work Packages, which will be organised into appropriate Phases. The work packages allow us to accurately estimate cost and schedule.

i. Create a budget and schedule using the outputs (a) to (h). For item (e) we deployed a short punch list documenting how technical data would be discussed, agreed, and formally signed off.

This punch list was as follows.

1. Hold technical sessions on specific components of the virtualised solution. Attributes we needed to capture included.

a. List of physical servers, which were candidates for virtualisation.

b. Archiving policy

c. Migration methodology

d. Content of templates for virtual server builds

e. Backup scheduling

2. Agree and sign off all meeting minutes.

3. Compile all meeting minutes from all technical sessions into a working Scope Statement and have the Scope Statement Signed off.

4. Create specific Work Packages which list each deliverables and the tasks needed to be completed.

The work packages were created by the technical staff assigned to complete the work per PMI Best Practice. The punch list was documented and distributed prior to the Kick-Off meeting.

The Kick-Off was schedule for a full day. An objective along with the agenda was distributed in advance. And then we held the meeting…

How did it go? (I can hear the anticipation in your voice.) They took to it like catnip. When I was studying to be a teacher, our educational psychology professors prattled on and on about how unruly children actually feel more secure, and thus better about themselves, once their parents and teachers establish clear boundaries. Once the boundaries are set, behaviour improves. What is true in the classroom is true in a project.

The moment we established the Project Phases, the Board had their roles and responsibilities defined, the technical staff had clear objectives and ground rules for gathering requirements, the project instantaneously changed complexion in a very profound way.

The Board understood how the schedule and budget would be established and then controlled. Technical staff held discussions, which were focused on project objectives. Near term objectives were discussed first, long-term objectives were set aside until an appropriate time. The project started to resemble . . .well . . .a PROJECT. We might have been employing a ‘cloud computing solution’ but the clouds over the project started to clear.

And all those hours I sat in classrooms, all that time spent studying; all of the stress endured before and during the test, paid off massively. It was all worth it.

My conclusions are this: Viewed from a seat at the back row of a classroom, PMI and PRINCE2 can resemble inflexible, academically oriented, not fit for real world, ‘nice but who has the time’ methodologies. I can attest that the opposite is true. If you thoroughly know these methodologies, with a bit of forethought, you can cherry pick the best of both as appropriate to your situation. It is not the knowledge but how you apply that knowledge, as the axiom goes. Used together, PRINCE2 and PMI can give shape and direction to the most chaotic situations. It just takes a bit of proactive strategic planning and the discipline to consistently apply your plan. The results can be miraculous.

How did the project turn out in the end?

The percentage of IT projects that fail is as high as 62% according to some studies. This project was not one of them. At the end of Phase 7: Handover to Operations, the project met all critical success factors. The successful realisation of all project objectives means that today our client can accelerate customer acquisition and increase market share.

We had our challenges – misaligned expectations on how the technology was to be used, personal conflict, change requests that were debated and re-debated - we had a bit of everything. But the foundations laid during that first Project Kick-Off meeting that established the processes and controls required to handle these seemingly inevitable project issues effectively.

We never got off track, we stayed on message throughout and we succeeded. Somewhere in a classroom, the seeds for this success were sown.

This success enabled my organisation to sell this client an entirely new project with a completely different objective – design, implement and enforce a new project and programme management methodology across the business. This kind of opportunity puts me right at the top of Maslow’s Pyramid. (It’s in the PMI PMBOK, you can look it up.)

Geoff Filbey has over eight years experience managing all aspects of complex, time critical international projects and programmes. He has successfully managed mission critical projects for Fortune 500 companies in a formal portfolio management environment from initiation to closure.

This version of the story originally appeared in PM Today print edition.October 2010