Viewing Posts by Kevin Korterud
5 Things You Never Want To Hear On A Project
| Starting out as project managers, we begin to recognize the signals that point to project risks. Initially, these signals come in the form of status reports, work plans and delivery metrics. As we gain experience, we learn to sense additional risk signals that come from observation and dialog. And those signals originate from project managers themselves. These signals sometimes go unheeded because the ability to act on them can typically be constrained. For example, there is fear of making project customers unhappy if you raise objections, unrealistic expectations and a false belief that these types of messages will somehow motivate the project team. In my experience, here are some of the signals that have pointed to a project headed down the wrong path: 1. "We'll start the project at the kickoff meeting." Many times, important project mobilization activities tend to be ignored in the haste to begin a project with a large group meeting. This fixation on the kickoff meeting causes key mobilization tasks to fall behind. Early action on staffing plans, on-boarding processes and communication mechanisms before the kickoff meeting are more important than making sure the chocolate chip cookies arrive in time. 2. "This project WILL finish on time and budget." This signal typically appears at the first sign of progress or cost slippage. As opposed to dealing with the root cause of the slippage, many times project managers will shrink scope to meet time and budget. Reducing scope has the effect of reducing the overall value proposition for the project. Address this tendency by allocating sufficient time early in the project to identify business success criteria independent of schedule and costs. 3. "The CEO is the sponsor for this project or program." Name-dropping typically emerges when there is a conflict over resources needed by multiple projects. Project managers hope that by presenting the CEO or other executive as a sponsor, it will create commitment to the project. However, CEO's and other executives usually do not have the luxury of time to serve as a sponsor on a project. Leverage stakeholder management activities such as a level of funding approval list to confirm the primary sponsors for the project. 4. "We are four weeks behind schedule, but we'll make it up in the next phase." Unless there is a large change of scope, one of the more the unfortunate laws of physics for projects is that any schedule slippage is likely to carry over to the next phase. The best approach is to be transparent about the schedule delay. By making the slippage transparent, you enable leadership team attention and corrective actions. 5. "I feel green." A green status indicator in a project report typically means that no issues are present. However, a green status indicator does not always tell the complete story. For example, despite deliverable dates that were slipping on one project, the project manager continued to declare a green status indicator. In an executive steering committee meeting, the leadership team challenged the project report. The project manager said, "I know the deliverable dates are slipping but I'm still feeling green." To promote project team and leadership confidence, employ objective project metrics such as planned vs. actual deliverable dates or earned value analysis to show the true status of the project. While tools, approaches and processes help manage delivery risk, recognize these signals and take the right steps to act on them. What have you found to be good examples of signals that point to risks on projects? |
A Different Mindset: From Project To Program Manager
| As a project manager, leading a project to success provides a feeling of accomplishment. Having been successful at several projects, project managers could see becoming a program manager a likely career move. But when PMO managers were asked about the most critical factors for success, developing the skill sets of project and program managers were an area of concern, according to PMI's 2012 Pulse of the Profession. As a result, many organizations will renew their focus on talent development, formalizing processes to develop competency. In my opinion, developing a program management mindset is a key first step to successfully transitioning to a program management role. For example, moving from the linear world of a single project to the molecular world of programs can be daunting. Plus, you'll face the new experience of leading other project managers. Here are some practices I have found valuable to adopting a program management mindset: 1. Think big picture A common misperception about programs is when they are viewed as one big project. Keep in mind that a program is an interconnected set of projects that also has links to business stakeholders and other projects. Adopt a 'big picture' attitude to the overall program and avoid fixating on a single project's details. 2. Create a project manager trust model As a project manager, you develop trust with individual contributors performing delivery activities. As a program manager, you have to develop trust with project managers. Create a common interaction framework with every project manager for progress reporting, resource management, etc. 3. Encourage project managers to say "so what?" As a program manager, you will deal with additional reports, metrics and other information that you didn't experience as a project manager. Encourage your project managers to start dialogs with "so what" outcomes. This will get right to the direct impact on the program. Have them support these outcomes with relevant information from their reports, dashboards and metrics. 4. Establish credibility with business leaders With programs, customers are typically in business functions. Immerse yourself and your project managers in their business. Training, site visits and status meetings held at business locations are good ways to immerse your team in the customer's business. 5. Develop long-distance forecasting skills Forecasting several weeks in the future is satisfactory with a project. However, a program with projects moving at different speeds and directions requires a longer forecast horizon. Set your forecast precision in terms of months, not weeks. In addition, look for multi-project forecasting considerations such as holiday blackout periods and external project dependencies. What have you found effective to make the mental leap from project manager to program manager? To discuss Pulse of the Profession on Twitter, please use #pmipulse. See more on the Pulse of the Profession. |
5 Tactics for Risk Collaboration in Specialty Software Projects
Categories:
Risk Management
Categories: Risk Management
| Many organizations choose to implement specialty software products as a business solution. The benefits of doing so vary from filling critical gaps in a company's portfolio of solutions and services to enabling a quick response to new regulations, such as health and safety mandates. Never assume that because a solution is smaller in size, you can take a relaxed approach to risk management. With enterprise resource planning (ERP) solutions, success requires collaboration between the project manager and the software provider to manage risks. Here are some successful tactics for risk collaboration with specialty software providers: 1. Encourage leadership engagement. While it is rare to meet a company CEO, it is likely you will work with the CEO of a specialty software provider. Early in the project, create a deep level of engagement between the leadership teams. For example, connect someone from your leadership team with the head of product development. An early leadership engagement will create a quicker path to resolve any issues. 2. Gain high visibility during analysis and design phases. During the early phases of a project, a high level of visibility will help you to avoid costly errors in later phases. Early visibility also results in a quicker path to understanding the overall solution. For example, conduct design sessions at the specialty software provider's office. 3. Align methods and terminology. Invest effort early on in the project to harmonize methods, phases, deliverable formats and milestones. Agree on the terms for completing a project phase, as well as common terminology. For example, define the difference between a customization versus configuration. When you agree on these things early on, it's less likely any confusion or miscommunication will pop up. 4. Make site visits. Nothing is more effective than talking with a current customer about their experiences with a specialty software provider. These discussions create visibility to both best practices and challenges. Utilize this outside view to refine your project risk approach. 5. Don't underestimate contingency. Even if a specialty software provider is smaller than an ERP company, it will still have the same fundamental delivery risks. Using a straight percentage for contingency may not be sufficient. Discuss with the specialty software provider a special contingency allocation to manage risks. Do you have any tactics for risk collaboration? |




