twitter2  fb2  in2

Ten Tenets of Fast Projects - Tenet #9: Communicate the purpose and status

Rate this item
(0 votes)
by Larry Pendergrass, Principal 

Tenet #9: Communicate the purpose and status

It is my opinion that, for any kind of robust project management, there is little chance of over-communicating to your team and your sponsors. Far more likely, you and your team are under-communicating, and it’s hurting your sponsorship and reducing the sense of urgency and therefore the speed of your projects. However, not all communication methods are equivalent. Communication must be a light burden on the team, and has the right material targeted for those consuming the information. It must be tailored for the audience intended and more often than not it should be simple and concise, requiring little time for others to pull the essential elements out of the communication vehicle. Some of your communications should be visible at all times as admonished by lean practices, but not all.

Reasons for communicating

There are three major reasons for frequent communications:

  • To generate buy-in
  • To generate synchronization
  • To generate feedback

Generating buy-in: I would further break down “buy-in” into two areas:

  1. Communicating purpose to your team
  2. Communicating credibility to your sponsors and your partners

Communicating purpose: Creating a sense of purpose will usually require a different approach for your project teams than for your sponsors. While your sponsors may be motivated by understanding the impact of the project on company financials and reputation, project teams tend to be more motivated by how the customers will benefit from the product. As the leader of a product development organization, you will need to take both audiences into account. You should deliver two separate messages tailored for the two audiences.

Communicating credibility: Another aspect of generating buy-in is creating credibility with others concerning your project team. This is generally targeted at your cross-functional partners and your sponsors, but there may be an element targeted at your customers or even key vendors, especially if they are intimately involved throughout the development cycle.

Depending on your department’s culture, its history and successes, creating credibility may be essential, or it may be placed in the category of maintenance. It may take much of your time, or may take very little. There is a half-life to any credibility, meaning it needs to be nurtured or it will decay. Clear communication to your sponsors and your partners is critical to keep support high and prevent needless special examinations, reports and presentations. Part of a leader’s job is to keep the sponsors informed and happy, and off the backs of the team members so they can get work done.

Generating synchronization: Strong communication is also essential to assure that all stakeholders in a project are aware of the current status so they can be prepared to take action when action is expected from their own teams. This need for synchronization is another reason to make sure your communication is clear, concise, up to date, targeted for the audience. Misunderstandings in the project schedule and status and resulting synchronization can cost the company significantly. However, don’t assume the best way to communicate is through a project schedule like a Gantt chart.

Generating feedback: Communication is a two-way street. Ideally your communication efforts will generate discussion and feedback for leaders, and these dialogs can lead to refinement of project execution approaches to better align with the complex and often conflicting organizational goals; dialogs that may also generate innovations, or reveal key information that has been largely kept in “tribal knowledge”, or unwritten learnings from many years of experience held in the heads of employees.

What to Communicate to Improve Speed

Choose carefully. Attention spans are short and it is essential to keep clarity and brevity at the forefront. Make sure your communication will drive speed, and be careful not to add too much “noise to the signal”. Examples of key items to communicate for speed are:

  • Speed metrics: You may track many metrics, but you should chose to communicate only the most essential ones to your teams, aligned with your strategy. For faster projects, your metrics should focus more on schedule speed than schedule accuracy. If your product development organization takes on a wide range of projects from simple software enhancements to large and complex hardware and software systems, it is not very informative to measure speed by the number of weeks or months it takes to complete a project. Instead, consider normalizing calendar duration by project scopes to come up with a relative throughput time. Communicate speed metrics for given projects, and the averages for the active portfolio. Keeping consistent speed metrics like these over time, coupled with the right improvement efforts, should show everyone that the speed is improving. (See Figure 9-3 below.)

  • Cost of Delay (COD): See “Tenet #5: Sharpen the prioritization” for more discussion about COD. COD should be estimated at the start of a project, re-visited frequently and communicated often in order to aid in prioritization and give a general sense of urgency for a given project. (See Figure 9-2.)

  • Project Status: Updates on a given project should flow on a regular cadence, not just driven by a checkpoint process. The frequency should balance the burden of generating the information with the value to the information consumer. A regular status communication should include a reminder of the goals of the project, a simple method to communicate issues in resources, project scope, project cost and project schedule, changes to key project financials including COD, and any key and verified successes or significant failures. Note that communicating verified successes and significant failures will gain leaders the reputation of being honest, fair-handed and quick with communication. No one wants to hear of this kind of information (good or bad) through the corporate grapevine. An example of such communication is the MPU (Monthly Project Updates) my teams would produce in the past (See Figure 9-6.) This is a one page summary with all of the elements described above. Another effective way to report on project status is with a project Boundary management tool, as described here.

  • Key Changes: Perhaps it is obvious that everyone needs to be aware of breaking news. This includes big changes in customers and their demands, of competitors and their offerings, and of the company and the support of the project. This news may change the project scope, the product definition, the required schedule or any number of project elements. Speed is essential in delivering this kind of news. The MPU (Figure 9-6) is one way, however other methods including live discussions may be needed depending on the urgency and the importance of the news.

  • Portfolio Status: Seeing the status for all projects in just a few common dimensions is important for team members as well as your sponsors. Come up with a simple way (see Figures 9-1 and 9-2 below) for representing status on dimensions such as Project Schedule, Project Cost, Product Scope (performance, cost, quality, etc.) and Project resources. Additionally, prioritization for the entire portfolio should be communicated, along with any other key Project Portfolio Management [2]material. All members of the product development organization should have some idea of how the department is doing at any given time and how their project compares with others.

  • Project Purpose: Although it may seem unnecessary, project purpose should constantly be reminded to the team and the sponsors – especially if there is a change. Let me expand on this thought below:

An example of Project Purpose: Working in industries such as medical diagnostic equipment, leaders don’t have to look far to find great stories of inspiration to help drive a sense of urgency for their teams. But you don’t have to work in medical products directly to instill and communicate a sense of great purpose. While I was the VP of NPD at an electronics instrumentation company, we made equipment used to test customers’ electronic designs in both R/D and manufacturing. Talking to these customers about their own customers yielded some great stories for motivation, and sometimes these stories hit close to home. In one such case, I learned from one of our directors of marketing that his father had recently had a pacemaker installed. The pacemaker was made by one of our best customers for a particular product class; and during the last couple of years we had sold critical pieces of equipment into both R/D for developing pacemakers, and manufacturing for assuring their quality. In fact, their manufacturing facility had rows and rows of racked equipment stuffed with our instruments, essential for testing these pacemakers. What’s more, the product requirements for the instruments of greatest usefulness to pacemaker design and manufacturing had been developed by this very same director of marketing. His product requirements had directly impacted his own father’s health and possibly saved his life. It was a fairly obvious step for me to take this story (with the director’s permission of course) and hold it up to the project team responsible for the product, and to the department as a whole to communicate a sense of purpose for our work in general. I would bet you would not have to look too far to find similar stories with your own products.

How to Communicate to Improve Speed

There are three categories of communications that help improve project speed:

  • Pushed through email
    Examples: Department newsletter, Monthly project updates and full portfolio performance.

    • Advantages: Large coverage, reaches everyone quickly.
    • Disadvantages: Frequently not read and understood. Don’t rely on this method for anything that must be known and understood.
  • Posted news items, either physical or virtual
    Examples: Obeya room [3], looped presentation on hallway video screen, posted metrics on intranet web site.

    • Advantages: Made available to everyone with a log-on (e.g. internal wiki) or access to the physical posting site (eg. Obeya room).
    • Disadvantages: May not be visited, read and understood. You can improve the frequency of visits by sending a link through email when key information is updated and available for viewing.
  • Presented live
    Examples: Daily stand-up meetings [4], Quarterly department meeting, gate/checkpoint review meetings, Monthly executive team project update meeting, Project Portfolio Management meetings, Seinfeld meetings [5], Out-Of-Bounds meetings [6], 1-on-1 meetings.

    • Advantages: Have the attention of the audience (1-on-1, voice conference, co-located presentation) and can tailor the message and understand whether it is being heard and understood.
    • Disadvantages: Requires planning and time allocation for all parties (sometimes significant).

 

Communicating through email: If your focus is speed, make sure your emails are short and easy to read. Have only the most essential information, with a clear way for people to solicit more if they need it. But don’t depend on email to communicate time sensitive material. We have made it so easy to send and receive emails, sometimes we forget that picking up the phone or walking to someone’s desk is more effective for time sensitive and simple communication. If you have more complex communication requiring data, charts, etc., sending this ahead through email will help when you do make that phone call or pay that visit.

Communicating through postings: Postings have the advantage that you can make available a wide variety of information, but it may be lost and fail to find an audience. You can improve this downfall by sending a link through email when key information is updated and available for viewing. This is true for physical postings (as with an Obeya room) and virtual postings (as with an intranet site or a video loop running in the hallway of your buildings).

Shown in Figures 9-1 thru 9-8 are some examples of communication through postings. This is not a complete list of course, nor should all of these examples be used at once. To choose to communicate in all of these methods may create more confusion than warranted. Rather, pick carefully to drive the main messages for the organization.

 

Figure-9-1

Figure 9-1: Example of Checkpoint Plans Chart for Entire Active Portfolio

 

 

Figure-9-2

Figure 9-2: Example of a Stoplight Chart (using fake data) 

 

Figure-9-3

Figure 9-3:[7]  Example of a Throughput Time Trends Chart (though mislabeled as Relative Cycle Time) showing average value for projects in active pipeline for throughput time through the front end (Pre-Dev) and back end (Post-Dev) of the process.

 

Figure-9-4

Figure 9-4:[8]  Sample of Schedule Accuracy Trends Chart showing average over entire active portfolio, schedule accuracy as % of remaining project for estimates set at three points in the projects.

 

Figure-9-5

Figure 9-5:[9]  Schedule Change Chart for particular project showing schedules set at various checkpoints, their changes over time and the % slip with respect to these estimates.

 

Figure-9-6

Figure 9-6: Monthly Project Update (MPU), 1 page with essential information

 

Figure-9-7

Figure 9-7:[10]  Slippage Causes Chart, Pareto showing most impactful at the left. Stacked bar shows slippage in various product development phases.

 

 Figure-9-8

Figure 9-8:[11]  Product releases over time displaying improvement in quantity and types of releases. 

 

Communicating live: Not all live communication is good or bad. But any communication that takes more time from a project than it gives back in effectiveness IS bad.

As an example, let’s look at the gate/checkpoint meetings. (See “Tenet #2: Think in Sprints”, for a brief discussion about stage-gate vs. phase-checkpoint processes.) There has been a major push in many companies over the last decade to eradicate project gate/checkpoint reviews from the product development process. I see this as treating the symptom rather than the disease. The issue is not the gate/checkpoint meeting themselves, but what these meetings have become and what is expected by the project team in preparation for the review. In many companies gate/checkpoint has always been, or has grown into a significant time sink for the project team. In many cases it is not now (and perhaps never was) designed to be a light-touch, low team impact check-in with sponsors. And in most industries, companies would take little risk and gain greatly in speed by overhauling this gate/checkpoint process. These meetings should become much shorter, with less worry about elegance and more emphasis on the essential questions to be asked and answered. Managers should not feel that their careers are made or broken by how prepared or refined they are. This kind of overhaul will be difficult for most companies, and will take distributing the responsibility more broadly for making many decisions. (See “Tenet #7: Decentralize the decision-making”.)

Other types of live meetings might sound like a good idea but can be horrible if practiced poorly. To give an example, some years ago I was a manager in manufacturing who was receiving new products from R/D. The project manager in R/D for one project had heard about lean product development and decided to give it a try. He eliminated all project meetings and other forms of communication and replaced them with a 15 minute standup meeting that took place every few days. He had no published project schedule, nor any other communication vehicle. So while his core team was motivated and charged up with the new process, his partners in other functional areas were left with no understanding of how to sync up their efforts and plan the resources necessary at the times they needed to be deployed. The result was a poor hand-off to manufacturing. The moral is that your communication process must take into account the needs of all project stakeholders, including your team, your peers, your partners, and your sponsors.

As you can see, each of these methods have their advantages and disadvantages and should be chosen based on the specific need.

In summary, your communication methods need to be tailored for the need, and for the intended audience. It should be clear, targeted and concise. It should consist of information essential to emphasize the strategy, and if speed is essential then the message should reflect purpose, status, plans and performance along the line of rapid projects.

In my last segment of this series – “Tenet #10: Remove the distractions” – I will argue that if you wish to have fast projects, you must eliminate as many of those tasks, events and general interruptions that disrupt the project team and deflect them from the fastest path to delivery.

 


[Project Status]“How to ;Control’ an Agile Development Project” by Scott Elliott, click here

[2]See my Ten Tenets of Project Portfolio Management for more information on PPM, available here

[3]A room set aside for a given project with essential project information, charts, prototypes, etc. From Lean practices.

[4]From Lean practices, short status meetings with key team members to sync up (usually at beginning of day)

[5]The term “Seinfeld Meeting” was coined by one of my engineers since it is “The meeting about nothing”. This is a meeting with one top leader and less than a dozen individual contributors, typically optional and without their boss. The promise is that the leader will not come with an agenda, but simply answer questions.

[6]Out-of-Bounds (OOB) meetings are held only when the project team has breached the boundaries on dimensions agree-upon with the sponsors. For instance, a team can feel free to continue work unencumbered by sponsors if the schedule doesn’t change by more than 1 month. If a boundary is breached, OOB meetings are held until countermeasures are agreed upon and a new agreement is reache

[7]Public information, presented at Oct 2010 PDMA Conference.

[8]Public information, presented at Oct 2010 PDMA Conference.

[9]Public information, presented at Oct 2010 PDMA Conference.

[10]Public information, presented at Oct 2010 PDMA Conference.

[11]Public information, presented at Oct 2010 PDMA Conference.

Leave a comment

Make sure you enter the (*) required information where indicated. HTML code is not allowed.

Corporate Headquarters:

TechZecs, LLC
1730 Kearny Street,
Suite F-3
San Francisco,  California
94133 USA

Principal and Founder

Dr. Scott S. Elliott
Telephone: +1.415.830.5520
Email: scott.elliott@techzecs.com
           info@techzecs.com

Grab our contact information

qr-linkUsing your smart phones, open your QR Code reader and quickly scan this image to save our contact information automatically .