ITT DUBLIN

PMBoK
A Project Management Methodology
Tim Cahill Student Number: x00097120 12/12/2011

A brief overview of the PMBoK project management methodology from a personal perspective and a reflection on learning about its use and application in a small student Group as part of the ITT EEP programme.

PMBoK

TABLE OF CONTENTS
BACKGROUND / INTRODUCTION ....................................................................................................... 2 W HAT IS A PROJECT? ............................................................................................................................ 2 W HY DO WE NEED PMBOK? .................................................................................................................. 2 W HAT IS THE PMBOK METHODOLOGY? ................................................................................................. 2 PRACTICAL APPLICATION OF PMBOK TO A PROJECT .................................................................. 3 LESSONS LEARNED ............................................................................................................................... 4 REFLECTIONS ON THIS TEAM-BASED TRAINING ........................................................................... 4 FEEDBACK? .......................................................................................................................................... 5 APPENDICES ......................................................................................................................................... 6 TYPICAL RESOURCE ESTIMATES ............................................................................................................ 6 TYPICAL PROJECT PLAN ........................................................................................................................ 8

2011 Tim Cahill (# x00097120)

Page 1

PMBoK
BACKGROUND / INTRODUCTION
WHAT IS A PROJECT?
In Business, the term project is generally applied to temporary groups of collaborative activities that are well planned and that are designed by organisations to bring about change. Change is typically very difficult to effect or to absorb by an organisation. Therefore, Projects are treated differently to business as usual operations because they are outside the normal business activities that an organisation usually performs. It is generally accepted that, for a variety of reasons which may include novelty, size, risk, uncertainty, cost, importance or combinations of these, projects need to be managed systematically in order to ensure successful outcomes. Projects are considered to be strategically or tactically important by management because the changes that they deliver are essential to the achievement of organisational objectives. Over time, a number of standards organisations have developed different methodologies to help their members to standardise the terminology and the processes that are used to manage projects in their particular industry or discipline. These methodologies include for example, PMBoK (construction), PRINCE2 (IT), Agile (engineering), Waterfall (business), etc. Although each of these methodologies has attributes or processes that are specifically designed to address unique aspects of projects within its own industry, they are all based on structured management concepts and have many similarities. This report will consider only the use and application of the PMBoK methodology and is designed to represent the authors views only.

WHY DO WE NEED PMBOK?

Every project should have a Project Manager (PM) who is given the responsibility and accountability for its completion. PMBoK provides the PM and the project stakeholders with the structures, terminology and processes to enable unambiguous project communications among stakeholders before, during and after the project lifecycle. It does not cover any of the technical skills or disciplines (e.g. estimation skills or HR Management) that may be necessary to actually carry out a project. The advantage of using PMBoK is to improve the probability of delivering a project systematically using proven methods that have worked well on other similar projects. This, combined with using the right skills and resources, should help you to complete a project successfully i.e. on time, within budget and in compliance with the agreed specification no surprises!. This is a very important management goal when one considers that, for example, the failure rate of IT projects alone is approximately 40%.

WHAT IS THE PMBOK METHODOLOGY?

PMBoK is an internationally accepted project management methodology designed by PMI in the USA. Within PMBoK, every project has four defined stages, each of which has its own activities, processes and outputs. The four main stages are: Initiation Stage: In this first stage, the overall project is described in terms of the scope of its objectives, the broad activities involved, the outline estimates of resources and timescales required, the benefits that will be derived and the potential risks that may impact on the project. The main output of this stage is a Project Charter report that provides the business case for authorising the project. It also specifies governance 2011 Tim Cahill (# x00097120) Page 2

PMBoK
procedures that will monitor the lifecycle of the project e.g. it identifies the Project Sponsor, the main stakeholders, Steering Committee processes and the PM assigned to the deliver the project. Detailed Planning Stage: This stage generally involves the production of a Scope statement, a Work Breakdown Structure (WBS), detailed estimates of activities and interdependencies, resources, timescales and the major milestones and deliverables involved. The detailed plan produced at this stage should include all of the above plus a Quality Plan, a Risks and Issues Log and a Responsibility Assignment Matrix (RAM). The plan should also contain a Change Control procedure which is a description of how any changes to the project will be evaluated and managed as the project progresses. Execution and Control Stage: In this stage, the plan produced (above) is used as the basis for carrying out and controlling the delivery of the project to the agreed specifications. Sometimes the Execution and Control processes are separated into two different stages, but they are generally carried out together because the Controls are normally enforced during the Execution Stage to ensure early reporting of any quality issues or deviations from the plan. This stage is generally the longest and most expensive stage of the project. In it, frequent meetings of the Steering Committee are held at regular intervals in order to monitor progress and to ensure proper governance of the project. This is achieved by providing guidance and decisions on Change Control authorisation, Risk Mitigation, Issue Management, Supplier Progress Payments, etc. Closing Stage: This final stage verifies the completion of the project, files all the appropriate documentation and compiles a report of any Lessons Learned for use on future projects.

Generally, the project steering committee will meet at the completion of each Stage of a project to monitor progress, review the outputs and quality, and to authorise any changes required. The committee and/or the project sponsor is also responsible for authorising the start of the next stage in accordance with the governance procedures in use.

PRACTICAL APPLICATION OF PMBOK TO A PROJECT

In 2009, I was involved in the delivery of a small IT system for a major Telco organisation which was an existing client. The project started out as a relatively small and insignificant system that looked like it could be handled easily by one or two technical staff and could be completed within 2 weeks. Because we were dealing with an existing client and we had already established a very strong working relationship, we treated the organisation of this mini project very casually. However, the Business Sponsor was very imprecise in defining both the requirements and the criticality of the required delivery dates. This meant that our sales proposal and SOW estimates were very informal and a lot of assumptions were made which later turned out incorrect. In effect, although the system was quite simple in itself, it was ultimately required to integrate with several other operational systems and the new solution was required to be demonstrated live to an international Board of Directors and VIPs within very limited timescales. This high level of integration and the tight delivery deadlines together introduced new variables into the project plan. These added significantly to both the Scope Statement (the dreaded Scope Creep) and to the potential risks of failure (Risk Log). However, these complexities only became apparent as the system was being developed and after a fixed price had already been agreed for the mini project. The result was a complete failure of the project i.e. the system was 2 months late, missed the Board demonstration deadline and my company ended up losing a lot of money due to the fixed price nature of the contract. In addition, we almost lost the entire client relationship! 2011 Tim Cahill (# x00097120) Page 3

PMBoK
LESSONS LEARNED
Based on what I have learned, if I was undertaking this project again, I would ensure proper processes were conducted at the Initiation stage of this project to ensure that we had a fuller description of the system requirements, the scope of integration, the criticality of the deadlines and the scale of the risks involved. Based on these, the size of the estimates for the project would have been more realistic in terms or the resources needed and the costs involved. In PM terms, I would have ensured that the project was treated in a more formal manner and that the four stage process was enforced for decision making and for reporting purposes. In particular, the PMBoK methodology could have delivered the following benefits for this project: By completing the Project Charter at the Initiation Stage, the stakeholders and reviewers would have seen any gaps in the integration requirements and would have had an opportunity to correct many of the assumptions that later proved to be wrong. A critical project such as this should also have had a better Communications Plan to ensure that Project Team Members and other Stakeholders were all up to date on the progress and on the mitigation handling for risks and issues. A Detailed Planning Stage could have provided a fuller description of the activities and in particular would have identified the enlarged number and size of the risks involved due to the greater technical effort involved and the very short timescales for delivery. The resulting enlarged Scope of Work would have produced more realistic estimates, timescales and costs. In addition, the use of a Change Control process together with Risk and Issue Logs would have prevented the Project Sponsor from believing that it was possible to make major changes to the Scope without consideration of the fixed budget and the delivery milestones already agreed. The Project Sponsor would undoubtedly have been annoyed during the Initiation Stage of this so-called mini project. She would believe that this was unnecessary overhead and over the top PM. However, when asked to approve the final Project Charter and related expenditure, I believe that a more professional PM approach to teasing out the requirement complexity and using the formal methodology would have been very much appreciated. In the end, this could have changed failure into success.

REFLECTIONS ON THIS TEAM-BASED TRAINING

I was quite sceptical when this exercise was first assigned to the class. From experience, I had reservations about the capability of random groups being able to cover the PM training materials successfully in a relatively short period and with very little subject matter expertise or proven ability to work effectively as a group. In our initial Team get-together, we assessed the PM knowledge and experience level of members and it was decided that I should be the leader of the group. I then encouraged the group to discuss and agree a structure that, subject to review of the Innovo content provided, could form the basis for everyone completing the assignment successfully. The objectives set by the group were: to complete the review of training materials provided, and to get everyone comfortable that they could complete their Report. I volunteered to review the standard material supplied and to provide feedback at the next meeting. We agreed that we would try to complete the training in 3 x one hour sessions that would be conducted after the following 3 EEP sessions if this suited everyone. We allowed for contingency of a further meeting in case it was needed. We also discussed 2011 Tim Cahill (# x00097120) Page 4

PMBoK
roles and communications processes and exchanged our contact details. Subsequently, the Innovo material was reviewed and a more detailed plan and schedule were distributed by email and this was adopted by all. Briefly, the plan for each meeting was that all members of the Group reviewed selected training materials in advance. Then during the session itself, we concentrated our time together discussing the reasons why these PM controls were necessary and where they are relevant in real life situations. This stimulated real interest and enthusiasm in the whole area of PM rather than just focussing on the vocabulary / terminology in use and memorising lists. The sessions were very interactive and I think they were also a good use of time no more than an hour each. The group worked well together and was respectful of all member contributions.

FEEDBACK?
When the last session was completed, we discussed feedback on the learning exercise itself. From this, the group consensus was that all members were very satisfied with the way that we worked together and with the learning outcome achieved. In comparison with other groups, we appeared to have completed and understood the PM materials supplied. What might we do differently next time? I would try to delegate more tasks to individual members so that they could participate more in explaining the slides and terminology. This might encourage more ownership of the content and process.

2011 Tim Cahill (# x00097120)

Page 5

PMBoK

APPENDICES
TYPICAL RESOURCE ESTIMATES
The following are typical estimates for an IT project: No. Stage / Task 1 Project Initiation Ph 1.1 Kick off 1.2 Devt. of Project Charter 1.3 Presentation of Project Charter 2 Detailed Plan 2.1 Requirement Estimate & Plan 2.2 Requirement Sign Off 3 Software Design 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 3.2.8 3.2.9 3.2.10 3.2.11 3.2.12 3.2.13 4 Solution Build Environment Build Development/Integration Environment DR Environment Business Analysis Workshop 1 Documentation Business Analysis Workshop 2 Documentation Validation Data Modelling Forms and list design Registration Management Inspection Templates actions Inspection Rules Regulation & Service Management Incident and Concerns Management Report Management # Elapsed days 3 2 2.5 0 3 1 0 0 3 3 3 3 5 6 6 10 7 21 7 10 13 0 0 0 1 2 0 0 0 0 5 5 0 0 10 0 Page 6

4.1.1 4.1.5 6 Test 6.1 6.2 6.3 6.4 6.5 6.6 6.7

Test Scripts Accessibility Testing PRE FAT FAT SIT UAT Support Defect Resolution

2011 Tim Cahill (# x00097120)

PMBoK
7 Documentation Functional Specifications Technical Documentation End-User Documentation Backup and Restore Guide Disaster Recovery Guide Training Materials 8 Training IT Staff Training End User Training 9 Go- Live 9.1 Deployment Prod & DR 9.2 Hyper Care 10 Close Out Effort excluding PM Time 11 Project Management Total Days All phases (15%) 0 5 5 3 2 2 3 0 0 4 3 0 0 1 5 0 2 0 166.50 24.98 191.48

2011 Tim Cahill (# x00097120)

Page 7

PMBoK

TYPICAL PROJECT PLAN

FIGURE 1 GANTT CHART SHOWING ACTIVITIES AS PER THE SOW IN A DETAILED IT PROJECT PLAN.

2011 Tim Cahill (# x00097120)

Page 8