Showing posts with label Sacred PM Practices. Show all posts
Showing posts with label Sacred PM Practices. Show all posts

Wednesday, June 9, 2010

Project: Stop the Oil Leak

Leadership, Ownership, and Trust are extremely important in successful large IT projects. I concluded this after conducting some research a few years ago (see Sacred PM Practices). In the years since, I have looked around to see how these attributes play out on my own projects, and in the world.

America's eyes are focused on the Gulf of Mexico and the oil spill. The stopping of the leak and cleanup could be considered a project -- it is a temporary effort, there is a beginning, some objectives, and an end. Just for fun, let's call this project, Stop the Oil Leak. During the next few posts, I'd like to share some of my observations of this project, and hope that you will share your own.

On May 27th, President Obama declared, "I am responsible." This would seem to address the attibute, ownership. Once he admitted that, it was clear who is responsible for the success or failure of this project. As an aside, I think BP is the owner of this project, but that probably speaks more of my personal views of accountability, and less of project ownership.

Was this declaration a good move by the White House? Do you believe it relieved the executives and employees of BP? Who do you think owns this project?

Tuesday, August 4, 2009

Sacred PM Practices – Bottom Line

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 – leadership, ownership, trust.

I am not suggesting that knowing how to create a project plan, or managing project risks are not important. I have come to believe that topics like leadership, ownership, and trust are little understood. How much time do you, or your project manager, spend on creating a sense of ownership among team members? Do you spend any energy cultivating trust?

We started the discussion of the research project, Sacred Management Practices, in a posting on January 25, 2009. This summary posting represents that last planned post about the the project. We have enjoyed some great discussion around the topics presented. You can find the full presentation at SlideShare.net under Sacred PM Practices.

Wednesday, July 22, 2009

Sacred PM Practices – 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 corporations.
  • 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.

Do you also find this to be the situation? If so, why? Is it simply easier to describe how to create a work breakdown structure than it is to describe how to create an environment of engaged team members?

Friday, July 17, 2009

Sacred PM Practices – 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.

Am I reaching here? Have I oversimplified the observations?

Thursday, July 9, 2009

Sacred PM Practices – 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 (see posting on June 15, 2009).

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

Why do you think that leadership, ownership, and trust are not prominent in literature, methodologies, and training seminars? I have been looking for these topics to be addressed for four years now. Only recently have I seen a couple of books and a seminar on Trust.

Wednesday, July 1, 2009

Sacred PM Practices – 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. Others, like Dr. Keith Mathis, have found the importance of creating an environment of trust. His posting can be found here on Project Smart.

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.

Has trust ever played into the success of any of your projects? Have you found the there is less documentation when there is a lot of trust?

Monday, June 29, 2009

Sacred PM Practices – Ownership

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

The majority of respondents in the study 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. There was the consultant who volunteered to cancel his contract if a software release was not successfully executed at a critical time. I also remember the CEO who found a project team in the office hours after a blizzard ended. No one from the rest of his company could make it into the office because of the snow-drifted streets.

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

When have you seen a project team show ownership of its success? Have you witnessed an especially engaged project team? If so, what made the team engaged?

Thursday, June 25, 2009

Sacred PM Practices – 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 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

Have you also had difficulty describing how leadership contrasts with management? Pawel Brodzinski tackled this question here. Do you simply know leadership when you see it?

Monday, June 22, 2009

Sacred PM Practices – Qualitative Factors Uncovered

My prepared questions were asked. Hundreds of pieces of information were organized. Trends were identified.

When I asked the successful project managers what I was missing, most project managers shared a few ideas that had helped their projects to succeed. 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

I was dumbstruck. In all of my project management courses and seminars, studying of PM textbooks, and discussions with senior management, I had never come across the importance of leadership, instilling a sense of ownership, and cultivating an environment of trust. After all, most of our status reports address schedule, budget, and risks.

When was the last time your boss asked you about your project team members’ sense of ownership? When has your status report commented on your client/customer’s trust in the project team?

Monday, June 15, 2009

Sacred PM Practices -- Findings Revealed

I thought the best way to share the findings and trends of the research project would be in podcast form. Please click the podcast listed on the right panel of this page to listen. The podcast, along with the graph below, provide a concise summary of what was found.

Thank you for visiting Management House. I look forward to reading your comments.

Saturday, March 14, 2009

Sacred PM Practices -- Lessons Learned

The final assumption that I tested in my project management research project (introduced in a Jan 25, 2009 posting), was a project’s collection and use of lessons learned. I wondered whether a difference between project success and project failure might be that a successful organization might learn from its own successes and failures.


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.

My experience with lessons learned is limited to a one-time meeting at the end of the project, where what is discussed (i.e., lessons) is largely or entirely ignored the next time around. When have you send lessons learned used? Has it made a difference?

Thursday, March 12, 2009

Sacred PM Practices - Change Management

Projects, large and small, must respond to a constant bombardment of proposed changes from customers, upper management, the business, the market, and perhaps even the federal government (e.g., regulatory changes). For a project to be successful, it must formally manage these changes. Or so I thought.

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.

I have rarely witnessed formal change management. I have often seen formal change management implemented, but rarely executed. There are forms, procedures, a change control board for those organizations very serious about change. From my viewpoint most of the time, the forms are not completed, the procedure description collects dust, and the change control board meets infrequently. Yet, some projects are successful.

Have you seen/lived formal change? Has it meant the difference between project success and project failure?

Introduced in a Jan 25, 2009 posting, this research project studied the project characteristics of large, successful IT projects.

Saturday, February 21, 2009

Sacred PM Practices -- Project Reporting

I next considered whether project recording could be a key factor in successful execution of a large IT project. Reporting has always been a rather dry subject, but perhaps I could discover something innovative in the frequency, topics, or audience of project reporting.

Frequency of Project Reporting







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







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

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

Did you find any surprises here? I have never really understood why a project report would not be shared with all team members. I have always found my name, next to a set of tasks with dates, to be very motivating.

Thursday, February 19, 2009

Sacred PM Practices – Stakeholder Involvement

Another topic that I pursued in my research, introduced in a Jan 25, 2009 posting, was the frequency of stakeholder involvement. I predicted that it would be nearly impossible to execute a project successfully without frequent interaction with project stakeholders.

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.

Can you believe that three of the projects reported a “rarely” for stakeholder involvement? Does your experience mirror the findings above? That is, are stakeholders typically involved daily or weekly?

Monday, February 9, 2009

Sacred PM Practices -- Define Project Schedule

“In preparing for battle I have always found that plans are useless, but planning is indispensable” is a well known quote from General Eisenhower. While I would not propose managing a project is the same as ridding the world of tyranny, his sentiment strongly suggests that we should pay careful attention to planning. If a project manager is to be successful, he or she should take great care in planning. Eisenhower didn’t mention the use of any single planning approach like the PERT Estimate, or Simpson’s Rule, but surely a planning methodology is necessary to build a project schedule.

Wrong.

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

This, by the way, was the most shocking discovery of my research project… not a single project used a formal estimating approach to define its project schedule. Others have found project management methodologies to be unnecessary for some types of projects (see We Don’t Need No PM Methodology by Pawel Brodzinski).

I tend to use one of two planning approaches. For unfamiliar types of projects, I will work with my technical leads using something like PERT Estimate. For types of projects where I am familiar with the activities to be performed, I just lean on my own judgment (a.k.a. relative comparison). It is quicker.

What about you? How much do you depend on formal methods of project planning?

Thursday, February 5, 2009

Sacred PM Practices – Dedication of Staff

It looks like one key to success is to have a dedicated project team. The term dedicated means that the project team members are not expected to split their time between projects. The pie chart below should serve as a healthy argument for acquiring dedicated resources.

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
I have found a dedicated project team to be a luxury. How many times have you worked on only one project at a time? I have never worked for a large company where matrix management is not the norm. Lost in Matrix Management points us to many of the problems of this type of organizational structure.

Have you ever seen a large project succeed without dedicated team members? Perhaps sharing the time of team members is fine as long as their work is not on the schedule's critical path.

(For information about Sacred PM Practices, see the posting on Jan 25, 2009)

Wednesday, February 4, 2009

Sacred PM Practices – Project Manager Selection

How is a successful project manager chosen? I’d like to say, very carefully. However, my research shows that the majority of project managers are not formally chosen. That is, there is little effort in identifying what the project needs in a project manager, and then matching the project needs with a candidate’s abilities.

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)

I asked my respondents to comment on the attributes that were important when selecting a PM for a large IT project. The following attributes were identified as selection criteria for project managers for the sample projects:

  • Communications skills – 6 responses

  • Business knowledge – 5 responses

  • PM came highly recommended – 5

  • Reputation for delivery – 5

  • Sound judgment – 4

  • Person was simply available – 4

  • Organizational skills – 3

  • Strong relationship with business community – 3

  • Technical knowledge -2

  • Negotiating skills – 2

  • Demonstrated leadership with business community – 2

  • Maturity level of person – 1

  • Similar work in the past – 1

  • PM was on the project’s steering committee – 1

Please note, some PMs were selected based on a few criteria. The number of responses does not equal the number of projects in the sample.

What do you think about the list of selection criteria? I was shocked at “Person was simply available.” This is an honest response, but weak. I have worked on many projects where “technical knowledge” of the project manager was considered critical. However, technical knowledge of the PM came into play for only two of the twenty-five projects.

Saturday, January 31, 2009

Sacred PM Practices -- Steering Committee

You have been given a large IT project to manage? One of your first tasks is to form a steering committee. Right?

Wrong. The findings from my research show that large IT projects do succeed without forming such groups.

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

I am not advocating the elimination of all steering committees. I am just pointing out that they are not always a prerequisite for success. Project Smart offers some of the best advice I have seen lately – form a steering committee only if the problems you expect to encounter might be solved by a steering committee. Don’t jump to creating such a committee without first answering the question, could a steering committee help the project to succeed? It sounds like common sense, but how many times have you seen a steering committee formed simply because the project is large?

Only two of the twenty-five projects in my research had effective steering committees. This suggests that effective steering committees are rare. Have you ever seen an effective steering committee? If so, what made it effective?

Tuesday, January 27, 2009

Sacred PM Practices -- Project Objectives

The findings of my research into what it takes to successfully manage a large IT project will be shared here on Management House during the next few weeks. First, let’s take a look at what the sample of project managers said about the use of 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.

I thought project objectives are what keeps people pulling in the right direction. What has been your experience with project objectives? Have they been vital? Are they overrated?

Sunday, January 25, 2009

Sacred PM Practices -- Assumptions to be Tested


The research of large successful IT projects asked questions to test the following assumptions:


  • 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.

Did I miss anything? Have you seen projects end successfully where other features came into play to help the project?