Sacred PM Practices

August 4, 2009.

Overview

Study Reviewed …………………………….…3

Results Shared ..…………………………….…9

Conclusions Drawn …………………….……22

Appendix -- Sample Described ……..…..33

http://managementhouse.blogspot.com/Sacred PM Practices A Study of Traditions in IT Project Management

Copyright © 2009 Jeff Edwards 2

Study Reviewed

http://managementhouse.blogspot.com/

Sacred PM Practices A Study of Traditions in IT Project Management


Purpose of Study

To identify the key factors that are present in

successful large IT projects.



Background/Context

As the size of IT projects increase, project success rates drastically decrease. In fact, for project budgets greater than $750K, project success rates are 33% or less.

Source: The Standish Group

Yet, a small percentage of these large IT projects does succeed.

What can be found in these few successful projects that can be applied to the greater number of similar projects?



Scope of Study

Successful projects that fulfill the following criteria were selected for this study:

Must have project budget greater than $750K Must be an information technology enabling business

solution

Final sample size is expected to be 50-200 successful large IT projects. Sample size for this report is 25 successful large IT projects.



Approach

The following activities were performed to reach the conclusions drawn:

1. Define interview questions based on set of assumptions

2. Identify respondents and example projects that meet the selection criteria

3. Conduct 25 interviews

4. Synthesize the information collected

5. Discover trends in the responses

6. Record observations



Assumptions Tested

Well-defined project objectives are important to success An effective Steering Committee is necessary Careful consideration is given when selecting a project

manager Most, if not all, project team members are dedicated to

project Interaction with stakeholders is frequent Project estimating (e.g., resources, schedule) is formal Senior management is provided frequent and detailed

visibility into a project as it progresses Change management activities are formal Projects learn from themselves by conducting

occasional Lessons Learned Meetings and applying what is discussed.



Results Shared




Project Objectives

Fewer than half of the projects defined, documented, and shared project objectives

Observations Project objectives were not even defined for 20% of the successful

projects. After defining objectives, 15% of the projects did not document the

objectives. Once 17 projects had documented their project objectives, 35% did not

share the objectives with the entire project team.http://managementhouse.blogspot.com/



Steering Committee

Only two projects had an effective steering committee

Observations 40% of the successful projects did not have a steering committee.

Of the 60% of the projects that did have a steering committee, only 2 were described as effective.



Project Manager SelectionMost successful project managers are informally selected

Observation

The selection of only 6 of the 25 project managers could be classified as formal or involving lengthy consideration (i.e., energy was spent identifying needed skills, reviewing candidates, and selecting an individual)



Brief Consideration of Project Manager

Communications skills ranks highest among selection criteria

Observations

Organizational skills of the candidate were considered only for 12% of the projects.

Technology knowledge of the candidate was considered for only 8% of the projects.

Whether the candidate had performed similar work in the past was considered for only 4% of the projects.



Dedication of Staff

Nearly all projects had dedicated teams

Observations Eighty-four percent of the projects indicated that the core

staff of the team was 100% dedicated. Only 16% of the successful projects reported a problem with

insufficient resources.



Frequency of Stakeholder Involvement

Nearly half of the projects experienced daily stakeholder involvement

Observations Of the 25 successful projects, 84% report a daily or weekly

interaction with stakeholders. Twelve percent of the successful projects had infrequent

interaction (i.e., less frequent than monthly) with stakeholders.



Defining a Project ScheduleMost project scheduling was limited to backing into a deadline

Observations None of the projects reported a formality (e.g., Global Efficiency

Factor, Productivity Adjustment Percentage, PERT Estimate) in scheduling.

Project managers for 64% of the projects had to make all interim milestones fit a final milestone.


Copyright © 2009 Jeff Edwards16

Frequency of Project ReportingNearly all projects reported on a weekly or monthly basis

Observations Thirty-two percent of projects reported on a monthly basis. Two of the projects (8%) never or rarely reported to senior

management.http://managementhouse.blogspot.com/



Topics in Project ReportingProject risks and schedule are typically reported

Observations Senior management chooses to review project risks and

project schedule for a significant percentage of the projects. Senior management reviews neither the project budget nor

changes in project objectives for the majority of projects

http://managementhouse.blogspot.com/ Sacred PM Practices A Study of Traditions in IT Project Management


Audience of Project ReportingDistribution of most status reports is limited to those who attend status

review meetings

Observations Sixty percent of the projects report that written project status

reports are distributed to only those who attend status meetings.

Even though sending an electronic report to the entire project team costs essential nothing, only 24% of the project managers do so.



Change Management

Less than half of the projects had a formal change management effort

Observations The majority of projects (56%) were successful without formal change

management procedures (e.g., documented procedures, forms to be completed, consensus approval).

Of the 44% that reported formal change management activities, many project managers reported that the formality was absolutely critical to the success of the project.



Lessons Learned

Most projects do not conduct lessons learned activities

Observations The majority of the projects were successful without conducting such

meetings. Of the 56% of the projects that did not conduct such a meeting, nearly

all of the respondents reported that such an activity should have been performed.



Conclusions Drawn



Identification of Key FactorsFor the purposes of this study, those characteristics which are

present in 4 out of 5 successful large IT projects will serve as the key factors in the success of a large IT project.

This 80% bar (i.e., true for 4 out of 5 projects), while arbitrary, is deemed as sufficiently large enough to be classified as a key factor.



Tested Assumptions



Only two of the tested assumptions showed a trend

Qualitative Factors UncoveredThe following characteristics were discovered to be present, to a

large extent, on most of the sample projects:

Project Leadership, as opposed to project management

Ownership of the project outcome

Trust among project members, stakeholders, and senior management



Project Leadership

Project Leadership is the ability to use interpersonal relationships to stimulate and guide people toward the accomplishment of a project.

Many of the respondents made a strong distinction between a project management and project leadership. While there are various definitions offered, a leader seems to be the one who achieves goals by influencing others, has a respect for expectations and perceptions, and directs others with a shared vision. A project manager, on the other hand, simply manages a project schedule, checks on progress, and tries to contain scope. Other comments from respondents included the following sentiments:

While a leader may not like office politics, he knows politics is part of the work environment. He does his best to use politics to his project’s advantage.

A leader makes an effort to understand all the personal agendas and expectations of the key stakeholders. He tries to understand why each does, or does not, want the project to succeed.

A leader is successful in establishing and managing relationships



Ownership

Ownership is a psychological bond between a project team member and the outcome of the project.

The majority of respondents volunteered their belief that a sense of ownership was critical to the success of their projects. Many discussed several perspectives on ownership. Respondents shared examples of project managers, project team members, the clients (both internal and external), and users exhibiting ownership of project outcomes.

The respondents did not know how to measure the level of ownership, but believed that they could state whether project team members exhibited ownership.



Trust

Trust is the confidence one has that another will fulfill his obligation.

Many of the respondents shared their conviction that trust among individuals was crucial to the success of their projects. These respondents reported that there was trust among senior management, the project manager, the project team members, the business community, and users.

One particularly interesting observation was that when there was trust in a project relationship, the relationship could sustain multiple mistakes (e.g., missed deadlines, budget overruns). These mistakes, of course, could batter the level of trust.



Unexpected Findings

Project Managers of successful large IT projects spend relatively little effort on activities declared important in project management literature, methodologies, and training seminars. Only two of the nine initial assumptions, dedicated project team and frequent interaction with stakeholders, passed the 80% bar.

These same project managers do focus on project leadership, build a sense of ownership, and cultivate trust among project stakeholders.



Possible Explanation

It may seem reasonable that with strong leadership, ownership, and trust in place, there is less of a need for the standardization of project management procedures/activities (e.g., resource estimation, risk assessment, change management).

In contrast, there is a need for standard project management procedures in the absence of leadership, ownership, and trust.

This possible explanation implies that standard project management procedures serve as a substitute for project leadership, ownership, and trust.



Topics for Consideration

Traditional project management resources seem to address topics that do not necessarily support the successful execution of large IT projects.

Project Management Institute claims to be the world’s leading publisher of project management information. Its books, newsletters, training courses, and seminars focus on traditional concerns such as resource estimation, risk management, and scope management.

American Management Association’s books, seminars, and self-study materials focus on traditional project management activities – setting measurable project objectives, estimating project costs, and the use of a Work Breakdown Structure.

Software Engineering Institute strongly promotes the establishment of repeatable (i.e., standard, documented) processes for such areas as project planning, project tracking, and change management.

Project management resources do not adequately address the qualitative findings of this study.

There are many resources written about leadership. The resources however, tend to address military leadership and the leading of whole companies.

There are few resources that address ownership. Some of the leadership books do include a sentence or a paragraph about why ownership is important to an organization.

There are extremely few project management resources that address trust among project stakeholders.



The Bottom Line on the Findings

Most project managers, project management instructors, and publishers of project management material are spending much effort on management topics that are of little importance to the success of large IT projects, and little energy on those topics which are present in many of these successful large IT projects.



Appendix

Sample Described



Industries Represented




Both Private and Public Sector Projects are Represented

Types of Projects Represented



Nearly Half of Sample Projects Addressed Customization of Software Product

Reasons Projects were Initiated



Too expensive to maintain the legacy system 5

Disparate systems did not produce detailed information 3

Enhance customer service 2

Provide better information faster 2

Replace outdated technology and processes 2

Simplify business and automate it 2

Comply with regulatory policy 1

Enhance online marketing 1

Improve accuracy of data content 1

Legacy system could not address current needs 1

Reduce poor delivery (e.g., schedule, quality) of product 1

Installed software product could not be used without project 1

Technology and processes were constraining the company 1

To attain technology leadership in banking industry 1

Users changed, so application was changed 1

Business

Sacred PM Practices