Every organization is broken down into three distinct layers, as Figure 4-4 demonstrates. Each layer has its own project objectives with various communication needs:
i Executive: Executives set the vision for the organization.
i Functional management: Managers determine the functions, tactics, and strategies for the entities within the organization.
i Operations: The workers perform activities to support the endeavors of the organization, satisfying the tactics set up by functional management, and supporting the vision of the organization, set up by the executives.
Each layer of an organization has its own interests and purpose. Each layer must support the layer above it.
•Steering Committee Meetings
• Project Presentations
• Project Summary Reports
• Project Status Meetings •Written Status Reports
• Project Status Meetings
• Informal Meetings •Written Status Reports
• Issues Database
As a project manager, you have to communicate with each layer of an organization, as well as with individuals and groups outside of the organization. As a software project manager, you have to translate technical info from the operational level so that managers and executives can track the project's progress. At every level of this pyramid, the terminology you use must be clear and relevant.
Two attributes affect your interaction with executives: the size of the company and the scope of the project. In a smaller organization you may communicate daily with the executives. Heck, you may even be an executive in the company.
In a larger company, you probably won't rub shoulders often with the president or CEO very often. Your interactions may be limited to an occasional briefing; the CEO may attend a kickoff meeting. If the project is large enough, you may do periodic status reports for executives.
Large projects in larger companies have a direct impact on a company's operating expenses, cash flow, and predicted profitability, so the success of a project may be closer to a CEO's heart than you imagine.
Here are some general guidelines for talking with executives:
i Keep it simple and quick. Executives want to hear what's happening with a project, but they don't want all the details, and they don't want to spend a lot of time. Don't belabor anything; say what you need to say and move on. These are busy people and they want summations. If they want or need more detail they'll let you know.
i Follow your plan. Your communication to executives may also be controlled by the flow of communications as described in your communication management plan. It may not be your place at all to discuss the project with the executives unless they ask you for information directly. Always follow the flow of communication just as you'd expect your project team to do.
i Be direct. When you speak with executives about your project, you want to be, as with everyone you communicate with, direct. If the project's going great, tell 'em. If the project is bleeding cash, let 'em know. Don't sugarcoat anything. Chances are executives will have heard bad news already from the functional layer of the company.
i Set up project summary reports as needed. Your communication management plan should define what types of reports executives receive, if any. Some organizations require project managers to complete project summary reports or dashboards, one-page snapshots of a project's health. These reports summarize
• The impact of the project
• The cost variance of the project
• The schedule variance of the project
• Milestones achieved and pending
In the middle of the organizational pyramid you find functional management. Functional management, also known as good ol' middle management, focuses on directing operations. This layer of your company contains the managers, vice presidents, and directors that schedule, manage people, and make decisions that affect a project manager's sanity.
Basically, managers want to know how your project affects them. Managers often have their employees on your project team. They want to know i When you'll need their resources to work on your project i How their resources will contribute to your project i How their employees are performing on the project i Whether your project is performing to expectations
You may often complete projects for functional management. In these instances, managers are stakeholders and want to focus on project performance. Your communication in these instances centers on i Overall project performance i Milestone reporting i Cost variances i Schedule variances i Scope verification
Depending on their role in your project, their power over you in the organization, and whether they have team members participating in your project, individual managers affect how and what you communicate with them.
The overall theme for communicating with functional managers is performance. Focus on communicating the performance of the project (if you're completing the project for them), or the performance of the project team if their employees are working on your project.
Your software project team is comprised of programmers, of course. Programmers need to hear the information that relates to them. They don't need fancy statistics and reports that you'll give to management and executives. They need relevant, applicable communication to help them do their job better.
Here's what programmers must hear from you:
^ What activities are pending: You need to let them know what work is pending and where the project should be at this point in time.
^ What activities are lagging: You must address issues with your project team when they are late. We all get behind from time to time, and without someone (namely you) urging programmers back to duty, activities will continue to slide, and your project won't be completed on time.
^ What risks are looming: You need to track risks that are in play or pending in the project and keep the project team informed. Risks are any events or conditions that can threaten a project's ability to succeed. Chapter 5 covers risks in detail.
^ What issues are being resolved: Throughout your project, issues may pop up to wreak havoc. Some issues include the quality of the project work and complaints from customers. You must address these problems by communicating them to the people who have the power to fix them. You can't hide under your desk and hope that the problems will just go away. They won't. Besides, under you desk isn't really that comfy.
^ Recognition: When your project team members are doing a good job, give them kudos. Sometimes it's appropriate to mention a job well done to a team member in private, but usually public recognition of a significant accomplishment is the best action.
Every project is different — especially when it comes to developing software, but there are some common themes you need to hear from your stakeholders. Here's the stuff you need to hear:
^ Progress: Your staff needs to trust you enough to report honest assessments on their work so you can get a heartbeat on the project progress. You'll be able to inspect the progress of the project and get an actual assessment of progress, but you simply won't have time to double-check your project team's progress every day.
^ Issues: Your project team sees the issues and problems in the project work before you do. You must establish confidence in the project team to report these issues so that you can document them, help them address the problems, and keep the project moving forward.
^ Risks: Risk identification is an iterative process. Your project team is closest to the work, so your programmers will identify risks that affect the project before you.
Some project team members may feel as if they're letting you down if they tell you about pending or new risks they've identified. Encourage them to share discovered risks so you and the team can deal with them.
^ Change orders: Instruct your team and the stakeholders on the proper method to ask for changes to the project scope. Your project team should not be doing changes on the fly, and all change requests should flow through you so can determine their validity and then catalog your decisions. Read Chapter 13 for more detailed information on change management.
i Encouragement and recognition: You need some encouragement. Your stakeholders, project team, and project sponsor, may not realize this. It's hard to ask for encouragement and recognition, but you can ask stakeholders whether they're satisfied with the project. If they say yes, thank them and count that as your encouragement.
Was this article helpful?
What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.