Join Doug Rose for an in-depth discussion in this video Communicating the impact of project changes, part of Project Management Foundations: Change.
As a project manager, you have to be able to simply and clearly communicate how changes impact the scope, schedule, cost or quality. One of the most widely used reports is a Gantt chart. You can see an example Gantt chart for a mobile application project in the course material. A Gantt chart has vertical bars to show the project's schedule. If your project is using the software, Microsoft Project, then the primary output is a Gantt chart. In the example chart, you'll see the vertical bars for the project's progress. Then there are arrows to show the interdependencies bewteeen the outputs.
For a mobile application project, you can see that the server needs to be purchased before the software is installed. Then the software needs to be installed before the staging environment is created. Gantt charts can be very useful for small discreet projects with few dependencies, but it doesn't take long for one of these charts to turn into a linear mess. Imagine a change to the budget for the purchase of a server needed for the project. With the new budget the server approval will be 2 weeks later than expected. This change will push back the date when the software can be installed.
This delay will impact when the staging environment is created. Now look at the Gantt in your example files. Imagine you're in a meeting trying to convince the procurement coordinator to speed up the server purchases. A vertical bar might not sufficiently communicate the impact of a late server on the project. Try to supplement your standard reports with sketches that would simplify your project's complexity. Keep in mind that the purpose of a report is to communicate. So don't be afraid to step outside traditional tools and create simple pictures or diagrams.
Try to remember these 4 things when you're creating simple sketches. First, simplifying is a creative process so don't be afraid to do some analysis and make some creative assumptions. Second, a simple chart can communicate complex ideas. Some teams don't like to create sketches because they feel it will trivialize their issue. On the contrary, most managers complain that they get too much unfiltered information. A good simple sketch is extremely valuable to stakeholders.
Third, stakeholders prefer to make simple decisions. A change request can have a profound effect on your project. If you can't easily communicate the impact of a change, then your project might get into trouble. Finally, a simple chart can communicate to people outside of your project. You'll need the ability to communicate your challenges to people who are not directly involved in your project. A few years ago, I worked as a project manager for a software development team. We held once a week stakeholder meetings.
They were basically meetings where the team would present the project's changes and challenges. Before each meeting the team would prepare project reports and Gantt charts. The senior developers would spend an hour or so updating the charts and spreadsheets. They would udpate the revision from 7.1.4 to 7.1.5. They would check off milestones and update the dependencies. It was all part of the rhythm of reporting. It was extremely detailed and complete. But there still was a consistent disconnect between the team and the stakeholders.
A summer intern joined the team later in the project. He never discussed the project releases or dependencies. Instead, he sketched out small stories on the team's whiteboard. He would present these sketches with smiley faces and arrows with X's and O's. It looked like something a coach might sketch out on their clipboard. The developers liked the sketches, but they thought they were too simplistic. They appreciated the effort and didn't want to discourage the intern so they stapled his pictures to the back of their formal report. At the next meeting, the stakeholders set aside the formal report and worked entirely from the sketches.
At the end of the summer, the stakeholders wanted the intern in all the meetings. He was seen as a key person who truly understood the project and should explain the requirements to the rest of the team. The intern wasn't a top developer. The long-time senior developers knew the system better than anyone, but that didn't matter. The intern knew how to simply communicate the project to stakeholders. He showed that it's not about what you know. It's also about what you can show. Those who can best simplify complex topics will be given greater authority.
So a good sketch will not only show the impact of changes, it'll also be a key asset when you're the one pitching the change.
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.