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

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:
Define interview questions based on set of assumptions
Identify respondents and example projects that meet the selection criteria
Conduct 25 interviews
Synthesize the information collected
Discover trends in the responses
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.

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.

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 Selection
Most 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 Schedule
Most 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.

Frequency of Project Reporting
Nearly 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.

Topics in Project Reporting
Project 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

Audience of Project Reporting
Distribution 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.

Identification of Key Factors
For 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 Uncovered
The 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.

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 http://managementhouse.blogspot.com/ Sacred PM Practices A Study of Traditions in IT Project Management Copyright © 2009 Jeff Edwards 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

Sacred PM Practices

by Jeff Edwards on Aug 04, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 3

Statistics

Sacred PM Practices — Presentation Transcript

http://www.slideshare.net	2
http://www.lmodules.com	1