Getting Documentation Right
Categories:
Project Planning
Categories: Project Planning
| Documentation is an important aspect of a project manager's job. We document to keep us aware of status on projects. We use it to stabilize spending and keep a paper trail of events and circumstances. So, what should you capture and how should it be maintained? Here are a few tips to make sure you're capturing usable documentation.
Now that you know how to maintain documentation, we'll review which documents should be retained in my next post. What are your must-have tips for documentation on projects? |
Why Realistic Goals Matter — and How to Set Them
Categories:
Project Planning
Categories: Project Planning
| One of the regular challenges I hear coming from the project management community is the idea that our organizations are setting unrealistic goals. This is a tremendous challenge because setting unobtainable goals can lead to project failure, low morale and a culture of insecurity. It's vitally important to spend time working with our project management offices (PMOs) and sponsors to develop realistic timelines and goals that are achievable in the short- and long-term. Why? Because this is going to help maintain motivation throughout the project as each milestone is obtained. Additionally, it will help you communicate progress more effectively to your sponsors and gives you the capability to set clear, reasonable expectations at the start of the project. Here are three ways you can set better goals that motivate your teams, sponsors and stakeholders:
While it isn't possible to control every variable on every project, a project manager can make great strides in team performance by using goals to set proper expectations. What helped you set proper goals in a recent project? Read more about PMOs and their impact on strategy implementation in PMI's Strategic Initiative Management: The PMO Imperative. |
Turn Chaos Into Success
Categories:
Complexity
Categories: Complexity
| Project managers usually advance in their careers by managing small, then medium and ultimately large projects. What project managers may not be prepared for is the complexity that comes with taking on bigger projects. Left unmanaged, this complexity leads to chaos and ultimately project failure. Why does this happen? A business system is characterized by processes and activities that work in tandem to deliver a specific result that benefits customers. Throughout a project's life cycle, it can encounter a number of business systems -- such as leadership systems (how leaders set values and organizational performance and governance) and customer systems (engagement strategy to meet customer needs and support that relationship) -- that independently and jointly put pressure on the project. As you segment the business systems further, you will find underlying, interrelated business processes and activities that create even more complexity. And as the project traverses along the value chain, more strategic tensions apply, such as competing research and development priorities or sales quotas. Projects that disrupt these systems and value chains promise new and improved approaches. But project managers must mediate the chaos this disruption generates to achieve project success. Organizations with less mature processes and fewer performance measures tend to put more pressure on project teams. In these organizations, the project team is responsible for navigating the chaos caused by increased complexity. Projects often devolve into uphill battles and ultimately fail. This demonstrates an inherent "inverse tension" between process maturity and project complexity. Reduce complexity by relaxing tensions. By understanding tensions, project managers can develop a management discipline that shapes the project plan and enables success. To create that discipline, follow these foundational steps:
I use APQC's Process Framework as one source to identify common organization business systems and processes, and their potential pitfalls. A team should identify the system's performance gaps to manage mediations and avoid negative impacts proactively. To assess the performance of business systems, I generally rely on the CMMI model (Capability Maturity Model Integration). I define the performance criteria according to the following maturity levels:
I also use simple checklists to assess the project capability of an organization and team to determine any preventative actions I can take in the planning phase. For example, asking a series of assessment questions that identify process maturity levels allows me to consider any gaps I need to mitigate to improve project performance. To analyze team-related project complexity, I leverage the characteristics outlined by U.S. authors Kathleen B. Hass and Amit Kumar:
I used these frameworks to reduce complexity and increase predictability when I managed a big project team that was working with a large number of suppliers. The project was highly complex, behind schedule and expected to go over budget. The team managed supplier payments by sending invoices to accounts payable once the related work was complete. Using assessment questions, I discovered the main problem was related to a large global transformation initiative, in which the purchasing team worked within limited regional relationships. I classified this as a high complex engagement because the team:
In my management improvement plan, I was able to clearly demonstrate what business system was failing, where in the system it was located and why it was underperforming. I created a clear path forward to restore performance, which resulted in reduced complexity, better alignment and lower costs. How do you create a framework to get a handle on complexity? Learn more about complexity on PMI.org. |
7 Steps to Project Planning Acceleration
Categories:
Project Planning
Categories: Project Planning
| What's a reasonable amount of time to devote to planning a project? I use this rule of thumb: If it is a low-uncertainty project (i.e., we've completed another with similar conditions in the past, with known technology and firm assumptions), devote at least 10 percent of the expected duration of the project to planning it. If it's perceived as a high-uncertainty project (i.e., one with new technology, new approach, uncertain conditions), devote at least 20 percent. But let's face it. Often, organizational pressure will not allow us to devote that much time to planning. So is there an approach that lets us reduce planning time but still do good work and come up with a complete, useful plan? Many organizations I've worked with use a project planning acceleration workshop (PPAW). This is an organized, closed-door, multiday session with the whole project team to focus exclusively on producing the project plan -- something that usually takes several weeks, completed in a few days' time. There are different ways of organizing such an event, but I usually follow these seven steps: 1. Plan the plan. Share with team members all of the project's background information. Send invitations with enough lead time and clearly state the session's sole objective, which is to produce a solid project plan. I often kick off the session stating that once we are finished, we will have a project plan that is roughly 75 to 85 percent complete -- and that we are going to accomplish this in a very short period of time. Therefore, total commitment is required from all participants. 2. Set the stage. What you want is an environment conducive to teamwork without distractions. Secure a room to host the workshop, preferably outside of the office. And don't forget to include a lot of food and beverages for the duration of the workshop. When people are tired, food helps! 3. Define the agenda. Depending on the complexity of the project, different workshop durations will be required, but three days is adequate for most projects. I often use an agenda that looks like this:
4. Use collaborative working techniques. Don't just project steps on a screen; make team members work together. When producing the WBS or the project schedule, use the participatory cards on the wall (COW) technique. For the risk management plan, brainstorm together to identify risks and ask participants to pin different risks on color-coded charts according to their assessment of probability and impact. 5. Document everything. Assign someone in the team to document everything produced. You may use Post-its to draft the WBS or the schedule, but these elements need to be recorded formally for when the project starts. 6. Assign tasks for completion. After the workshop is finished, the project plan won't be completely finalized. Usually certain parts need more research or analysis. Assign specific team members to complete outstanding pieces and establish a deadline for completing these elements that were initiated at the PPAW. 7. Kick off the project. Once the project plan is deemed completed, host one more session to make a final review of all the elements, especially those that needed further research. Combine this activity with a formal project kick-off meeting -- the end of PPAW and the beginning of your project. In my experience, when a team is co-located and completely focused for a specific period of time to create a plan, it yields better results. Have you ever run a PPAW? How has it improved your project? |
Adjusting to Team Time Warps
Categories:
Stakeholder Management
Categories: Stakeholder Management
| Have you ever wondered why one person is always late for meetings while another one is always early? Chances are you're dealing with people who see time differently. For some, time flows from the future into the present and on to the past at a steady rate of 60 minutes every hour. Others see time as a river carrying them forward to an uncertain future. And while everyone is aware of the three elements of time -- the past, the present and the future -- cultures see these in different ways. Western European cultures tend to have a strong future focus -- what's happening in the present is focused on securing a good future outcome. The past is relatively unimportant, since "you can't change history." Cultures with a present focus let go of the past, don't worry about the future and fully enjoy the experience of the present. This focus can be a wonderfully relaxing experience, but it can also lead to the need for immediate gratification and short-term payoffs -- traits of many "youth" cultures. More traditional societies -- for example, those found in Africa, Asia and southern Europe -- tend to have a past focus, looking to preserve their history and respect family and society elders. For them, the present is a continuation of the past, and there's not much point in doing too much planning for an uncertain future. In these societies, the Western view of time as a strictly linear function of seconds, minutes, hours and days is seen as very limiting. Understanding these different perspectives can help you in a project environment. For example, someone with a strong present focus will see the discussion they're currently engaged in as important and consider it inappropriate to cut it off just to be on time for a meeting. But if that meeting is organized by a forward-looking person with a strong time focus, there will be problems. One way to decipher where you and your team members are in the "time warp" is to use U.S. psychologist Thomas J. Cottle's Circle Test. Grab a sheet of paper and draw three circles on the page, arranging them in the way that best shows how you feel about the relationship between the past, present and future. Use different size circles to indicate relative importance and separate or overlap the circles depending on how much influence each one has on the others. Here are two examples that illustrate the different ways people view time: The purple circles represent a strong future focus with the present feeding into achieving future outcomes. There's little connection to the past. This is typical for a lot of time-conscious project managers focused on planning their projects (a future focus) and then implementing the plans (a present focus). The blue circles show a strong present focus firmly grounded in past experiences and traditions. The present is a bit more important than the past, but the future is not really connected to the present and of lesser importance. Don't expect someone with this perspective to be very interested in planning for an uncertain future or being on time for meetings. Their view of success is built on the strength of existing relationships and systems. The Western/project management focus on time can be effective, but it can also be dangerous, particularly in cross-cultural teams and when dealing with clients with a different time focus. The stress of missing an impending deadline can affect people's health, cause then to sacrifice their relationships and lead to shortcuts in quality and missed opportunities. Is it really worth destroying value by de-scoping a project just to achieve a deadline (especially if it's artificial)? A more balanced view may be that while the deadline is missed, there are opportunities to deliver 100 percent of the scope, identify additional hidden value, and maintain a healthier and happier project team. The optimum answer depends on the circumstances of the project and the time focus of key stakeholders. What's your time orientation and how does it fit with the rest of your team and other stakeholders? |





