Category Archives: Change Management

Project Management Techniques Change Management

Your Project Will Change

You led your team through a very thorough requirements gathering process. There was brainstorming and walk-throughs of the product functionality. Multiple groups contributed and reviewed the results. Additional analysis and review went into deciding which of the requirements would really make it into the scope. There was plenty of intelligent debate. And now finally, the project scope document has been signed.

Everything has been agreed upon and there will be no changes. Right? Wrong! Your project will change. You might begin to think, “What does she know? She wasn’t there. She did not see all of the work that went into agreeing upon our project scope.” You are right. I have not been following you. Still, your project will change.

What you have done is helped to ensure that the changes that occur either stem from unforeseeable circumstances or are truly useful enhancements or result from changes in the organization or political climate. Your project will change.

Even with the best planning possible, random things can occur. Previously stable business partner can go out of business and cause you to seek out new suppliers. A certain type of material may not hold up to testing. A new regulation may be imposed on your industry. A product may not function as designed. Testing might reveal a flaw. Sometimes unforeseen events bring about change.

As the project moves along, your team members will develop a better understanding of the work that is being performed. Your customers will develop a better understanding of what they really need. New ideas will evolve. You are not going to tell all parties to stop thinking, to stop coming up with new ways to make your product or service even better. You want the good ideas to keep flowing. If a change to the project is valuable enough, then a change request should be approved and the change should be incorporated. Your project will change.

To your surprise, your project sponsor who seemed happy and stable in her position announces that she has accepted a position outside your organization. Her replacement supports your project, but has different ideas about the project objectives and about what you and your team should really be creating.

Say it with me now, “My project will change.”

And it is going to be all right. The amazing work you did with your requirements and your scope document was well worth the effort. By spending time gathering requirements and agreeing upon scope, you have created a good baseline for the changes that will come. You and your team will recognize change. You will be able to have intelligent conversations about what these changes mean to your project.

Let the changes come, you are ready for them.

A Tale of Two PMOs

I recently came across a statistic that states that 50% of all Project Management Offices (PMOs) fail. It seemed high to me. But when I reflected on my own personal experience in setting up two different PMO’s I can tell you that my experience supports that statistic. One PMO was successful and one PMO was not. Of course two experiences is hardly a solid scientific sampling. None the less it has prompted me to bring you a tale of two PMOs.

The first PMO I was involved in had support from the very top. Our Executive Vice President was very much on board with the idea of the PMO. She could see that projects were floundering and she could see that each project was being managed differently and that this was leading to confusion. And so she tasked one of her directors with the creation of a project management office or PMO. In turn he brought in an expert in project management and an expert in PMO organization.  He selected some of the top project managers from the department and brought them into the PMO. Together they conducted research and went to seminars and hired the best consultants. Everything looked good.

The Vice President told all of her directors what was happening and how she expected their full support. They all enthusiastically declared that they couldn’t wait for the results. They were all very happy to know there was going to be a group of people who was going to help them run their projects more efficiently. At least that’s what they said in public. Behind the scenes the PMO team was having a different experience with those same executives. It seemed that most of those executives were too busy to meet with them to discuss plans and processes. It seemed that those executives didn’t have any resources available to meet with the members of the PMO. And when members of the PMO invited people to discussion sessions and training on project management methodology nobody showed up. When asked about their participation, every executive denied that they were refusing to participate with the PMO. They blamed schedules and resource constraints and said that the PMO was being unreasonable and so it went back-and-forth with no real progress or solution. Out of desperation the members of the PMO started working around the executives. They started going to some of the people who were running projects and who were new to running projects. They offered help. They offered mentoring and support.

By working directly with those who could benefit immediately with what they had to offer, the PMO began to experience some success. But alas it was too late. The bickering back and forth at the top level and the lack of progress lead to the dissolution of the PMO. The members of the PMO all learned an important lesson. We learned that company culture played such an important part in the success of a PMO. What we experienced was our own company culture. Our culture was nobody ever said no to something in public. Nobody said they wouldn’t do something or support something. They just did not do it. And if someone decided not to do something, nobody not even the Executive Vice President would make them do it.

Grassroots was the way in which we experienced some success. By grassroots I mean going directly to the people who are going to use what you’re creating and engaging with them and helping them and having them help create your processes and your methodology. And that leads to the tale of PMO number two.

A few years later at the same company a few of us who had worked on that first PMO found ourselves working together in another division. This division had a small PMO and they wanted it to grow. Surprisingly those of us who have participated in the first PMO were called upon to help. It was surprising because they knew our previous attempt had not been a success. We were called upon because we had the battle scars or lessons learned from the other PMO. We knew the company and we knew the culture. And use those lessons learned we did. We really socialized our PMO. We had an open house with games and suggestion boxes and of course fun food. We invited people to planning sessions, we walked around and spoke to all of the executives in informal and formal settings. We asked for their opinion, we asked for their feedback, and we did not announce or create any new policy without the involvement of the majority of the group. Was it a lot of work? You bet. Was it slower? Absolutely. But the time we spent doing this was time well spent.
It was part of the plan and part of the process. We didn’t make unrealistic deadlines for the growth of the PMO.

We created deadlines that assumed input from all concerned parties. We created drafts expecting people to come and tell us what they hated and what they loved. We assumed an attitude of “We are the PMO how can we help YOU succeed. Did we make everyone happy? Absolutely not. There were definitely some people who still did not trust us or the idea of a PMO and wanted to do things their way. Some of them came around, some did not. But in the end by working within our culture we were able to support projects and bring about positive change. And that was really the point.

If you are curious about PMOs and you are looking for ideas on how to move forward with a PMO (and also Project Portfolio Management), check out this free eBook from Keyed In Projects on Why PMOs Fail, http://www.keyedin.com/keyedinprojects/resources/ebook-why-pmos-fail

There is no reason for you to experience anything but success!

Project Managers: Make Change Control Part of YOUR Formula for Success

As a new project manager it was glaringly obvious to me that my success was largely dependent upon customer satisfaction. I knew that I needed strong collaborative relationships with my customers. I needed them to respect me and trust me to get the job done. I needed them to help keep the project priority high and to provide financial support and subject matter expertise.

I loved giving them good news and I hated giving them bad news. For some reason I came up with this equation:

Announcing new requirements (or any change in direction) as a scope change = Bad news

ChangeManagement1And this is when I learned, my wonderful customers with whom I had amazing rapport and respect had no clue why the project was late or why it cost more money.? Why, it was as if all of those conversations and agreements about adding five more days to development for more in-depth error messages had never occurred.? How could this be?

Sure my customer was happy; the end result was exactly what they intended all along.

No changes occurred; everything was in-scope from day one. This was simply another case of Information Technology taking too long.

And I had learned a new equation:

Skipping change management = Undocumented overages plus poor customer perception

I moved on, determined to be a better project manager and to continue to enjoy a great working relationship with my customer.

You can bet that on my next project there was change management. I documented it in the project plan and I reviewed it with the entire team. And when the first change surfaced, I helped my customer by filling out the change request for them! Talk about customer service, this made it easy. Now all my customer had to do was review and approve the form and off we went.

As you may have guessed, this did not make it easy. Now the perception was this was a form that had to be filled out by Information Technology for Information Technology in order to keep the project moving. I was still missing customer buy-in. And so I learned:

Change management without customer participation = Documented overages plus poor customer perception

I did not give up on change management; instead I learned that I needed my customer to be my partner in the change management process. They needed to understand and support the process. They needed to see the value of tracking changes and I needed to understand that expecting their support and participation was good customer service.

Some of the lessons I learned along the way:

  • Assume a change management process as part of your project.
  • If your current environment does not have a process, introduce a process. Invite input to the process and allow others to change and grow the process. This way you will ALL own it.
  • Do not over engineer your change management process. Set up rules and standards that will allow for rapid processing of change requests. Set up rules and guidelines that are appropriate to the size of the effort at hand.
  • Never act apologetic for expecting customers, project sponsors or team members to issue change requests.
  • Documented changes support better estimating for future projects.
  • Documented changes help customers to better understand the true scope of their request and the true nature of their requirements.

With no change management in place, there is no accurate accounting of project scope, schedule and budget. This is a disservice to all. And this means:

Skipping change management = Poor customer service

Oracle Primavera Enterprise PPM Virtual Summit

Guest post by Travis Anderson

Earn PDUs while learning how Oracle Primavera is adamant about riding the world of project failure. Get started by visiting the registration screen at Oracle Primavera Enterprise PPM Virtual Summit. http://vshow.on24.com/vshow/primavera2010/#home

Once you get your login information, go to the Auditorium and watch Joel Koppelman, Sr. VP & GM of Oracle Primavera Global BU, as he delivers an informative key note presentation called Enterprise Project Portfolio Management: Helping You Manage Change in a World of Constant Change. Joel indicates that projects create change, result from change, and require change. Project Managers need to be ready to handle change by being tolerant and equipped to respond in a dynamic and collaborative fashion. The processes and tools of yester year are simply no longer effective.

Also visit the Resource Center, Exhibit Hall, and Networking Lounge to read white papers, listen to podcasts, and learn valuable insights on industry trends.

I hope you enjoy this virtual summit. Please share your perspectives by leaving a comment.

Change Control and Managing Expectations

Finishing projects on time is very important; but holding yourself accountable to a baseline is only as valid as the change management process you have in place. The definition of “on time” changes based on context and how expectations are managed.

Change happens on projects, and in my experience most of that change is not handled well. When scope increases on the project it only results in scope creep if there is no formal change management in place to update the baseline. As real changes are approved by a valid Configuration Control Board (CCB) and the process around those changes, impacts to scope, schedule, and cost need to be updated in the project baseline.

Here are two scenarios with the inevitable increase in scope as the project progresses:

Scenario 1 – No/poor formal change control

As the project progresses, the customer discovers additional scope that they would like added to the project. The project manager accepts the new scope with the intention of “fitting it in” somewhere. Even if a log is kept that records this additional scope, the customer expectation for delivery date has not changed. They expected the product to be delivered on October 15th. Now when the due date starts getting near, the project is falling behind and either 1) misses the delivery date or 2) cuts corners in testing or other areas to make it on time.

Scenario 2 – Good formal change control

As the project progresses, the customer discovers additional scope that they would like added to the project. The project manager and team work with the customer to fully understand what they are asking for. Additional scope WILL cost more. The customer should decide whether delivering on time is the most important factor (time-constrained project) or if the delivery date can be pushed out to accommodate the additional scope. If the project is time constrained, additional resources (or overtime cost) will be added to the project to finish more work in the same duration.

Working together, the project team and customer do an impact analysis to identify how much additional work is really required, how much longer it will take, and how much more it will cost. Whatever the outcome, the customer expectations have been updated to reflect the NEW baseline delivery date and cost. The CCB can choose to reject the change request and continue as planned, or approve the change request and update the baseline.

————————–
In both of the scenarios above, the same scope was added. In Scenario 1, the project will be delivered late or with an unthoughtful decrease in quality or functionality. Because expectations were never updated, this project is late. In Scenario 2, the project may be delivered later than the ORIGINAL baseline, but because good change control and management of customer expectations is in place, the TRUE baseline has been updated to reflect customer choice and the reality of the project. This project is not late (at least not due to expectation problems).

When you work in aerospace as I do and are working towards a launch date, you must be on time. That is why on a time constrained project it is so important to have effective change management and customer expectations management in place.