In one of my previous posts, I suggested ways to maintain documentation. And as you know, documentation is very important -- it's the essence of knowledge transfer. The beauty of documentation is that it allows us to avoid the pains of reinventing a series of events that may only reside in a person's mind as a singular experience. It can also lead us to extract some aspect that may move our project from uncertainty and unknowns to more useful information.
So, once we have taken the precautions I mentioned in my previous post for generating clear and valid documentation, the question becomes: What project documentation should we always have and hold on to? I would suggest, at a minimum, the following:
The charter. It is the closest disclosure to everything the project should touch on. It includes a high-level look at the project: resource list, budget, timeline, assumptions, constraints, risks, other areas of impact and dependencies, a brief description and an immediate focus.
Budget background and expenditures. This information typically details the budget spending and directs you to possible future support, if any can be used again.
Sources. These include contacts and stakeholders; where information is stored; direct lines of contact; contacts who would be next in the succession; who and where to reach out to in case of additional needs; and where information stemmed from, and how it should be categorized and even prioritized.
A status report of risks and issues in their most recent form. These items show the progress that has or has not been made and is especially helpful in communicating to a new project manager (or yourself, if returning to a project) where to pick up. This status report can even help determine the project's resource needs.
Scope. This tells you what should have been the focus of the project. It also helps determine whether there needed to be an extension to this scope or if something different should be embarked upon, such as a total new project or maybe a revamping of the current scope.
Are there any types of documentation you find significant to have during a project and to hold on to after a project closes?
Project trouble can hit from a blind spot, even though you tried as much as possible to prepare for issues. You did a risk analysis when you took the project on, and even tried to be ready to mitigate unknown issues.
As I advised in my previous post, do an assessment to determine the problem. Figure out what needs to be fixed, or if the situation is even fixable. If the project seems to have reached a point of no return, here are some tips on how to pull it out of trouble:
Finally, keep in mind that not all trouble devours all. Before panicking, calmly look to areas that will guide you to a solution. You may even find your project is more sound than it seems.
How do you confront trouble on your project?
First Steps Toward Recovery
Categories: Lessons Learned
In my previous post, I discussed points to help prevent problem projects. Here, I'll talk about what to do when you realize an existing project is headed for trouble.
Let me try to explain it like this: If you are driving a vehicle, what happens when you see a red light? You know that when you come to it, you will stop. After the light turns green, you will look both ways before proceeding. When our projects hit red lights, we as project managers must also stop and assess our environment.
As you look at the big picture, review your inputs, factors and the overall sanity of the project. Examine your risk register or issues log. Is the status of risks or issues showing something that was missed and needs to be addressed immediately? For example, something easily overlooked is when the schedule for applying security patches is on the same timeframe as the testing phase. This sort of impact can cause testing to grind to a halt, with the team unaware of the source of conflict. A review of the risks or issues log would have highlighted these events.
Another source to review is your budget plan. Have unplanned circumstances arisen, such as the need to produce more prototypes? Does the acquisition of resources require additional time? Is equipment becoming obsolete or in need of repair? Expenses such as these caution you to slow down and reevaluate your budget. Be aware that ultimately, you may need to secure a renewed budget approval.
Consider client relationships as well. Are your clients becoming unsatisfied and impatient, regardless of how well you're completing deliverables and meeting milestones? If so, you may need to allay fears or even compromise on a feature of your project. Perhaps that means reconfirming a budget forecast, or something as simple as picking up the phone and calling the client with an impromptu status report.
One last piece of advice: Take a look at lessons learned. It's very likely a previous project manager may have outlined specific pain points on similar problem projects. These will provide valuable insights that even the most technically experienced project manager can lean on. They're good for figuring out what to do in grey-area situations: when it was difficult to get management signoff on a needed budget increase; how a concern was handled when a client change request was denied; or how to garner support when team conflicts arose.
After you recognize there's trouble ahead, how else do you assess the size of the problem?
Any project manager or team member can appreciate the value of historical data to learn from previous project experiences and reduce associated project risks. But have you considered whether it's available in a format that appeals to Gen Y team members?
The traditional way of capturing lessons learned is by using a template to record the lesson and saving it in a repository. But given their collaborative nature, Gen Y team members may perceive this as a limited source of information, based on the experience of a single individual.
Instead, many Gen Y team members are pushing for a more collaborative approach, in which all project documents can be classified under categories, linked to wikis, referenced in blogs and be shared via micro-blogging or clouds. The goal is to prevent having valuable project documents stuck in one person's hard drive.
This new approach stands in contrast to the traditional view of knowledge as a finite asset, living and managed inside the organization's boundaries. With a more collaborative approach, it doesn't matter if the author of the lesson learned left the company, because the organization still "keeps" that employee's knowledge when she or he is gone.
One happy medium is to limit the collaboration environment to the employees in the organization and restricted to the project team until the project is completed. The adoption of this new way of managing organizational process assets will require the endorsement of senior management. You will also need to implement a strategy that's attractive to all team members for full adoption of a new collaboration approach to lessons learned. To do so, introduce a collaborative approach that best suits your project environment. Perhaps task the Gen Y team members to present this new method and highlight its benefits to the project during a team meeting. Finally, remember that individuals take time to accept new practices, so have patience.
How easy or difficult would it be for you to embrace a collaboration approach for lessons learned? What are the benefits for your team and your organization?
We've all seen the signs a project is about to blow up — a schedule goes awry, a budget exceeds its tolerance threshold. To prevent this, consider taking a few measures:
Prevention requires preparation, listening and awareness. As you interact with your team, your sponsors and other project managers, be sure to listen and look for pain points that warrant investigation.
In my next post, I'll talk about recovery steps when facing a troubled project. For now, please share what you do to prevent troubled projects.