What Do You Mean, "Done?"

     What do you mean, “Done”?

     It’s obvious to you what “done” is. It’s also obvious to me.

     Problem One:

     Your “done” is different from mine.
     We have two different understandings, but each of us thought everybody has the same one, the one I have.

     No necessarily so. What’s “obvious” to each of us can be a highly personal, built over long experience that was not shared by the other person

     We don’t even think about such things, until we’re surprised when one of us says, “What do you mean, ‘Done? You didn’t do (whatever).”

     To which the typical reply is, “Why should I do that? It’s not part of this piece.”

     Followed by, “Of course it is. How could it not be?”

     And so on.    

     It’s not unusual that the gap goes undetected – or ignored – until we have gone our separate ways long enough to cause costly and/or permanent damage. The effects on team cohesion and collaboration can be just as serious as the damage to the project itself.

     Problem Two:

     On each of the multiple paths through a project network, there is no way expectations established in the original planning phase will remain unchanged once execution is under way.

     If the effort is truly a project, it includes unfamiliar parts that must be handled with speculative estimates. However carefully such plans are developed in the beginning, the effects will not completely match expectations.

      Decisions are made to meet the small and large variances that inevitably show up. The accumulation of those decisions gradually changes the direction and outcome on each path, often without the team members noticing the extent of what’s happening.   

     Since the partners don’t pay much attention to the minor variances as they arise and are dealt with, the results and effects often aren’t tracked and properly reported.

     Different paths diverge from their original tracks, while unwary planners hustle along their own shifting ways, expecting activity junctions that now can’t happen.

 

     Problem Three:

     The solution, of course, to get the change information to affected teammates so they can adjust. But there’s more.

     The change at your end must not be allowed to mess up other parts of the project, in ways you have no way of knowing on your own. So, the leaders of other work packages will need to be involved, as – of course – will the project manager.

     The familiar statistics of project shortfall and failure result in no small part from this reality of uncoordinated change. Communication continues to bedevil project managers because it demands focus . . . at the same time equal focus must be applied to the many other complex and pressing matters within the project manager’s responsibility.

     Estimates must be tracked and adjusted; team members and collaborators require direction, responses, solutions; sponsors must be informed and consulted. Each of these classes of stakeholder requires different information and a different relationship, and none of it can be handled on autopilot.

     Communication tends to fare poorly is this environment.

     It’s easy to put off taking time to talk and listen, to inform parties not close at hand, and to detect and overcome barriers. Other challenges are in your face, but everyday communication needs are unobtrusive.

     When failure becomes urgent, it often is in some kind of explosion that derails the process, at least temporarily, and it always results in permanent damage.

     Perhaps more often, failure of this vital function ruins projects by quietly eroding the quality of the work and the ability of the team members and other stakeholders to collaborate.

     A most insidious characteristic of the communication challenge is this: Time and attention devoted to developing, disseminating and digesting information is time taken away from the work, and vice versa. One category of management performance always diminishes the quality of our attention to the other.

     What can project managers do about this?

     While much of the work requires dealing with sudden and unexpected priorities, communication always will be with us. It is the area of distraction that can be tamed.

     How? Tools.

     Much of the information that must be communicated is in predictable areas, and in definable categories. With careful planning, fill-in-the-blanks formats save enormous amounts of time and speed accurate information along established channels.

     The Project Management universe has countless ways of organizing projects and equally diverse means of communication. Some of the methods and instruments are useful, but too many are complicated and imprecise.

     One frequent design error is to cram too many purposes into a tool. An example is the Project Charter, or whatever tool establishes the foundation of the project. Too often, the charter is cluttered with to-do stuff that obscures the clarity of the basic purpose of the project.

      A project charter, whatever it is called, should be limited to essentials that will remain available for reference throughout the life of the project. Major changes along the way must be added, but not the nuts and bolts of execution.

     The charter essentially expresses the organization’s intentions in establishing and directing the project. The charter should:

             

·         Establish the clear, concrete outcome the effort is to achieve;

·         Identify the sponsoring organization’s strategic goals the project is

Supporting, and the desired return o2n investment;

·         Include major risks, barriers and resources that can be identified at this point.

·         Name the specific organization executives who are sponsoring the project,  

controlling its direction and resources, and advocating for it within the  

sponsoring executive ranks;

·         Specify the resource organizations, internal and external, that are

committed to the success of the project.

·         Include other information the sponsor considers pertinent to this project.

     Operational tools then are built upon the Project Plan in a hierarchy of increasing detail:

     A Work Breakdown Structure then granulates the Project Goal into

     first, categories of    activity (such as research, marketing, construction) that

           will be    required to achieve the Goal; and,

     second, the mini-goals for work packages that will be necessary to fulfill the   

          needs in     each category.

     Work Package Specifications, which detail the activities, schedules, assignments,

     A Project Schedule, which is built from the Work Package Specifications.

     Risk Management Reports, tracking the progress of efforts to avoid or mitigate

               threats to the project.

     Such ordering of intentions, ongoing project activities and results falls naturally into formats, reusable in successive projects and improvable as part of lessons-learned sessions.

     It also clarifies definitions and specifies requirements, makes “status meetings” much more targeted and useful, and supports productive collaboration.

     In sum, the whole journey from “T0-D0” to “Done” is obvious to everybody, and the same for all.

 --

  --   SEE ALSO:  When the Buck Never Stops

http://jimmillikenproject.When the Buck Never Stops.com/2016/11/when-buck-never-stops.html

--

Question: Is there a communication process that is both efficient and effective for Project Management? You’re welcome to offer your ideas and experiences in the comments below.