Teams and organizations are constantly plagued by project execution errors and failures. These failures create an execution gap -- a gap between what an individual and/or team plans to do and what they actually do instead. Just as retention rapidly degrades after learning, so does project execution after strategic planning. So what can be done?
In 1885, Hermann Ebbinghaus, a German psychologist, famously demonstrated a theory concluding that people start forgetting what they learn as soon as they learn it. In his "forgetting curve" study, he demonstrated that humans forget half of what they learn within an hour of learning it, and by the following day, they have forgotten a full two-thirds of the new information. Since Ebbinghaus' study, psychologists have discovered that there are many ways to improve retention and memory; however, if memory is so fragile, what is its impact on project execution and strategic planning – getting the things done that you and your team should do?
The key to successful communications is asking stakeholders what they need communicated to them, and then follow through and provide it to them. I have heard many new project managers complain of "backseat drivers" on their projects, always going around them, asking team members for status (i.e., asking "are we there yet?").
I suspect the reason for this is that many project managers act as if project status is top-secret, classified information that only the privileged few with top-secret clearance can receive. Consider that the project is operating on a "need to know" basis and your stakeholders really need to know. Mark it as confidential if you are so inclined (or if it is appropriate because you are actually dealing with confidential or sensitive data), but send out accurate and timely communications on a regular basis.
By managing the work and reporting the progress regularly to stakeholders, you will avoid the "backseat driver" syndrome.
Another benefit of this is that you will create the environment for the team to do their job uninterrupted without numerous disruptions from various stakeholders asking for status updates because you fail to provide updates sufficiently. If this is happening on your project, know this: it is the project manager's fault.
I'll share a story from my career.
In my colleague's haste to leave the office for vacation, she failed to update a stakeholder on a critical deliverable that was due at the end of the day. I happened to be at the wrong place at the wrong time and became the unintended recipient of his frustration. He was extremely agitated and looking for anyone who could give him an update. I was able to get an update for him in less than five minutes and he had the information he needed and the assurance that his deliverable was on target. For something that took so little time and effort, it created a lot of unnecessary stress, frustration, and ill will. So ask yourself, is it worth it?
It is remarkable how many failing projects I have seen rescued throughout my career by improving communications and reporting. In many cases, beginning project managers did not understand their role and were not collecting or disseminating the information accurately or in a timely fashion. The work was in fact being completed; however, it was not being managed, thus timely handoffs (i.e., for dependent tasks) were not occurring between project team members. Nor was there any evidence of progress being presented to stakeholders. Therefore, stakeholders had the perception that the project was way behind schedule and they reported as such to their management. Of course, this causes a rippling effect of escalations. As soon as an experienced project manager reigned in and managed the team and got a handle on the work actually being accomplished, status was adjusted to reflect accomplishment accurately, handoffs between project team members occurred, and the project quickly was back on track. Performance reports present evidence of the work. Without them, how will anyone really know what is being accomplished along the way? The team works hard. It's your job as project manager to ensure this is reflected in your performance reports.
Don't forget to leave your comments below.
Kanban can change your life. More specifically, it can change your professional life and how well you manage your projects.
Kanban provides an enormous range of invaluable capabilities to projects, such as efficiency, focus, communication, limiting work in process, prioritization, and visibility on status. There is great value for your teams using Kanban and for all team members regardless of their role. This article will take a look at some of the benefits reaped from implementing Kanban into your process.
Co-written by Richard Larson
Small projects have unique challenges over larger ones. Because they're small, it's tempting to skip the planning process and start executing the work. This phenomenon is especially true if projects perform tasks similar to previous work, which in turn leads to a natural tendency to skip planning and to start doing the work. Then, essential steps are sometimes omitted, done out of order, or done later than desired. Likewise, costly mistakes can occur when risks are missed by executing too soon. A small project that isn't planned enough can also ignore critical stakeholders, causing both resentment and rework.
"That's a slam dunk!"
"Just pass the puck (or "give me the ball"), I'll put it in the net!"
"All I needed was a decent set up, and I could have slammed it home!"
"Who dropped the ball?"
Volleyball Setter: Fixing the Problems"You touch every other ball and, if you screw up, you only have one more person to back you up. You can't go hide in the corner." - Kerri Walsh, Olympic Gold Medalist
Whether your project is about improving an existing product or service, managing change or implementing a new system, the same basic considerations are required when managing projects. Get these right and you will manage a successful project. Get them wrong and your project will be thwarted by challenges, issues and problems.
I hear this sentiment often from students who are new to project management or working in organizations that are new to project management.
Many of the business analysts, project managers and organisational leaders we work with lament their inability to appropriately communicate and influence the stakeholders with which they work. Needing to get a point across or to inspire the required action, they spend significant energy trying to share their passion or urgency for attention to the business matters at hand. Often it falls upon deaf ears or becomes lost in the tsunami of information we all have to handle.
Typically their messages are not wrong or misplaced and their sense of need is quite real. Why then do so many of these communications fail to achieve the desired result? Are they failing to utilize the right vocabulary for their target audience?
As a project manager, you will need to manage people to get the work done. And most of the time, the resources won't report directly to you. So you need to learn to manage without authority. Thus understanding how to motivate people is critical. Also, you will need to leverage the appropriate leadership style depending on the situation.
Typically relying on saying "because I said so" simply doesn't work. If you have kids you may have already discovered this. No expert study is required. Fear and intimidation doesn't really work either, particularly in the long run. You may already have or eventually will encounter this type of manager. They are typically easy to spot. But if you don't catch on to the numerous unsubtle clues, just look for the department with the high turnover.
Parts 1 and 2 of this series presented practices that are useful and effective for laying the foundation for a successful project and planning the project. In this article, adapted from my book Practical Project Initiation, I’ll suggest six good practices for estimating the work you’ll have to do to complete they project.
Practice #12: Estimate based on effort, not calendar time. People generally provide estimates in units of calendar time. I prefer to estimate the effort (in labor-hours) associated with a task, and then translate the effort into a calendar-time estimate. A twenty-hour task might take 2.5 calendar days of nominal full-time effort, or two exhausting days. However, it could also take a week if you have to wait for critical information from a customer or stay home with a sick child for two days. I base the translation of effort into calendar time on estimates of how many effective hours I can spend on project tasks per day, any interruptions or emergency bug fix requests I might get, meetings, and all the other places into which time disappears.