Join Doug Rose for an in-depth discussion in this video Looking for signs that a change is necessary, part of Project Management Foundations: Change.
As a project manager you want to keep surprises to a minimum. It's often during these quiet times when the team is the most productive. You should catch your changes in a steady stream and not in a downpour. How do we go from quiet to stormy? There's some warning signs to avoid a flurry of changes. Beware of the quiet before the storm. If you're not receiving change requests, don't assume it's because there are no changes. Instead assume that the stakeholders are too busy to care about your project. Stakeholders almost always try to customize improve.
If it's too quiet, you need to get ready to catch a bunch of backed up changes. This usually happens when your stakeholders finally focus on your project. Just think of the line from every scary movie ever made. One person says, "Seems quiet." The hero says, "Yeah, too quiet." Then there's a flurry of unpleasant activity. That's how you should think of backed up project changes. One stakeholder creating a bunch of changes can cause a chain reaction where their changes impact other stakeholders.
Then there a bunch of new changes when their changes impact other parts of the project. With a project, silence is not affirmation. Affirmation is affirmation. Make sure that your changes are being closed with a sign-off. Only then can you assume that they won't change. Otherwise be very suspicious if there's not a steady flow of change requests. As a project manager you want to strive to reach a point of changlibrium. That's the point where the changes coming in match the time devoted to your changes.
If your developers are too busy with change requests, try and improve the process. Otherwise, your team will always be working on day-to-day fixes. You want them to develop for the long haul. Most projects are long hauls. Get a rhythm. If there is back up then knock o some doors and get some stakeholders to focus on your project. As a project manager, you sometimes need to shake the tree to create changelibrium. If your're running an agile project, you'll be hungry for changes to maintain a sustainable pace.
Agile project use changes to sprint the project to completion. Instead of detailed planning, these projects welcome changes as tiny course corrections. Sometimes instead of listening for changes, you as a project manager need to pitch a change. You might request a larger budget or ask the stakeholder to change the scope of the deliverable. Once clear sign that you need to pitch a change is the overall satisfaction of the team. Team members usually spend at least 40 hours a week at work.
Assume that your team members will try their best to do a great job. Many project mangers feel that without their leadership the team would devolve into complete inaction or worse. The truth is is that the majority of team members place a high priority on fulfilling work. You need to make sure that your developers believe in their own work product. I've never been on a project where the development team thought that the deliverable was low quality, but the stakeholders accepted it as high quality. The developers are the front line of the project.
If they think the output is unacceptable, you need to pitch a change to the stakeholders. Remember that for most organizations the project management role has evolved into a true analyst role. You should prevent some of these challenges and not just report them. Le'ts say that during our mobile application project you notice that the developers are frustrated with the database. The developers say that the database software has a new version. They feel that the new version will save a lot of time because the functionality is now included.
They're frustrated because they don't want to spend weeks developing software that's already obsolete. The older version of the database software was included in the original plan. You talk with team and then pitch the stakeholders to change the original budget. If you don't pitch a change, then you take the risk that the software will need to immediately be retooled. That might make some of the stakeholders unhappy. Stakeholders may not always anticipate these changes. Pitching a change will help keep the requirements aligned with their expectations.
Along the way, learn how to effectively manage your project for change requests and deal with common obstacles. Also see how to find the balance between too much and too little change—either can be threat to your project.
Lynda.com is a PMI Registered Education Provider. This course qualifies for professional development units (PDUs). To view the activity and PDU details for this course, click here.
The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.
- What are project changes?
- Planning for changes
- Accepting or rejecting a change
- Understanding the risks
- Learning from your changes<br><br>
- The PMI Registered Education Provider logo is a registered mark of the Project Management Institute, Inc.