The 3 Things That Transcend All Project Approaches
Human Aspects of PM,
New to Project Management,
Categories: Agile, Best Practices, Change Management, Communication, Complexity, Facilitation, Generational PM, Government, Human Aspects of PM, Innovation, IT, Leadership, Lessons Learned, Mentoring, New to Project Management, PMOs, Program Management, Project Delivery, Project Failure, Stakeholder, Strategy, Talent Management, Teams
by Dave Wakeman
Recently I had the chance to engage with Microsoft’s social media team about some of the issues I have been covering here. Their team brought up a question you may have asked as well: How do you differentiate between “digital” project management and project management?
It’s an interesting question, because I firmly believe all projects should be delivered within a very similar framework. The framework enables you to make wise decisions and understand the project’s goals and objectives.
I understand that there are many types of project management philosophies: waterfall, agile, etc. Each of these methods has pros and cons. Of course, you should use the method you are most comfortable with and that gives you the greatest likelihood of success.
But regardless of which project management approach you employ, there are three things all practitioners should remember at the outset of every project to move forward with confidence.
Every project needs a clear objective. Even if you aren’t 100-percent certain what the “completed” project is going to look like, you can still have an idea of what you want the project’s initial iteration to achieve. This allows you to begin work with a direction and not just a group of tasks.
So, even if you only have one potential outcome you want to achieve, starting there is better than just saying, “Let’s do these activities and hope something comes out of it.”
Frameworks enable valuable conversations. I love talking about decision-making frameworks for both organizations and teams. They’re valuable not because they limit thought processes, but because they enable you to make decisions based on what you’re attempting to achieve.
Instead of looking at the framework as a checklist, think of it as a conversation you’re having with your project and your team. This conversation enables you to keep moving your project toward its goal.
During the execution phase, it can give you the chance to check the deliverable against your original goals and the current state of the project within the organization. Just never allow the framework to put you in a position where you feel like you absolutely have to do something that doesn’t make sense.
Strong communication is the bedrock. To go back to the question from Microsoft’s social media team about digital vs. regular project management: the key concept isn’t the field or areas that a project takes place in.
No matter what kind of project you’re working on and in which sector you’re in, the critical skill for project success is your ability to communicate effectively with all the project stakeholders.
This skill transcends any specific industry. As many of us have learned, it may constitute about 90 percent of a project manager’s job. You can put this into practice in any project by taking a moment to write down your key stakeholders and the information you need to get across to them. Then put time in your calendar to help make sure you are effective in delivering your communications.
In the end, I don’t think there should be much differentiation between “digital” projects or any other kind of projects. All projects benefit from having a set of goals and ideas that guide them. By trying to distinguish between different project classifications, we lose sight of the real key to success in project management: teamwork and communication.
What do you think?
By the way, I've started a brand new weekly newsletter that focuses on strategy, value, and performance. Make sure you never miss it! Sign up here or send me an email at email@example.com!
The Three Levels of Success
Categories: Project Failure
By Rex M. Holmlin
As project managers, we would like our projects to be successful. Successful projects are more fun and, as a general proposition, our bosses like it better when our projects are successful. But how can we set our projects up for success?
A helpful first step is to define what success is. For many of us, that means meeting scope, cost and schedule targets. However, I will argue that there are three levels of project success we should think about:
1. Project-level success
2. User-level project success
3. Enterprise-level project success
For a project to be truly successful, we must be successful on each level.
Project-level success is the area most of us are most familiar with. Success at this level means we meet our scope, cost and schedule objectives. When we meet these objectives, many of us are looking for a ticker tape parade down the hallway. However, we are only looking at part of the success equation.
User-level success means delivering the benefits that the users desire from the project. While our users, and other stakeholders, may be interested in scope, cost and schedule objectives, the truth is we can meet project-level objectives and still have a project that does not deliver the benefits the users and stakeholders were looking for.
At the enterprise level, senior leaders in our organization are interested in having the projects that we execute make a positive contribution to key metrics at the enterprise level (profit targets are one example). We can meet project-level objectives, but not make a contribution to key enterprise-level metrics.
In a recent webinar, I asked the participants whether their organizations defined success at each of these levels. Approximately two-thirds of attendees felt their organizations had well-defined project-level objectives, but less than half of those felt their organizations set clear and well-defined user/stakeholder- and enterprise-level objectives
It is often quite challenging to meet scope, cost and schedule objectives. However, our projects will still fail if we do not deliver the benefits users and other stakeholders desire and make a contribution to key enterprise-level metrics. As project managers, we need to ask questions about the benefits users desire, and understand the key enterprise-level metrics we can contribute to. The more specific we are, the greater the chance we will have a successful project. When it comes to project success, ignorance about the other levels of project success is not bliss.
Please drop me a note and let me know if your organization defines all three levels of project success.
By Dave Wakeman
Last month, I wrote about how you can become a more strategic project manager. This month, I want to continue exploring the topic by focusing on a few ways to make sure your projects have strategic focus.
1. Always Ask “Why?”
This is the essential question for any business professional. But I am aware that asking the question can be extremely difficult—especially in the organizations that need that question asked the most.
Asking why you are taking on a project is essential to the project’s success or failure. Using the question can help you frame the role that project plays in the organization’s goals. It can also allow you early on to find out if the project is poorly aligned with the long-term vision.
This can make you look like a champ because you can make course corrections or bring up challenges much earlier, saving you and your organization time and money.
When asking about a project’s strategic value, you may find it helpful to phrase it in less direct ways, such as: “How does this project fit into the work we were doing with our previous project?” or “This seems pretty consistent with the project we worked on several months back—are they connected?”
2. Bring Ideas
As the focal point of knowledge, project managers should know where a project is in meeting its goals and objectives. So if you know a project is losing its strategic focus (and therefore value), generate ideas on how to make course corrections or improve the project based on the information you have.
There is nothing worse than having a team member drop a heap of issues on us with no easy solutions and no ideas on how to move forward. As the leader of your projects, don’t be that person. To help you come up with ideas to move the project toward success and strategic alignment, think along the following lines:
· If all the resources and effort expended on the project up to the current roadblock were removed from consideration, would it still make sense to move forward with the project?
· What actions can we take that will help alleviate some of the short-term pain?
· Knowing what I know now, would I suggest we start or stop this project? Why?
3. Communicate! Communicate! Communicate!
On almost any project I work on, more communication is a good idea. This is because the more the lines of communication are open, the more likely I’m to get information that will be helpful to me and my ability to achieve the end results that I’m looking for.
As with most things in project management, communication is a two-way street and loaded with possible pain points and missteps. As a project manager looking to deliver on the strategic promise of your projects, your communications should always be focused on information you can use to take action and move your project along.
To effectively communicate as a strategic project manager, ask questions like these:
· What do I need to know about a project that will have a material impact on its success or failure?
· What can I share with my team or stakeholders that might help them understand my decisions?
· What information does my team need to take better actions?
As you can see, adjusting your vision to become more strategic isn’t too far removed from what it takes to be an effective project manager. The key difference is making sure you understand the “why” of the project. From there, you need to push forward your ideas and to communicate openly and honestly.
What do you think? How do you bring a strategic focus to your projects?
By the way, I've started a brand new weekly newsletter that focuses on strategy, value, and performance. Make sure you never don't miss it, sign up here or send me an email at firstname.lastname@example.org!
By Kevin Korterud
I’m amazed at how often I receive requests for help creating an effective risk management process. These inquiries usually come from organizations with a risk management process that hardly anyone uses. Stakeholders, program managers, department heads and executives are mystified about why nobody is declaring risks on their projects, which can create the false perception that everything is going fine.
Why does this happen? One reason is that project managers believe making risks visible to leadership could impair their efforts. Another reason is an organizational culture that creates a negative perception of risks. For example, I have seen some highly entrepreneurial companies foster a mindset of rugged heroism, which causes project managers to think they have to fix everything themselves. In this project environment, project managers worry that escalation to leadership will be seen as a sign of weakness.
In fact, there’s no use pretending any project is risk-free. Risk management is an essential part of any project: Whether you’re climbing a mountain or changing a light bulb, there are always risks. For anyone who’s ever been leery about flagging risks, or is just looking for some new approaches, here are five tips.
1. Think of risk management as a way to get what you need, when you need it.
Project managers rarely have the financial or command authority to change schedules or release additional funding—that’s leadership’s job. For this basic reason, declaring and escalating risks enables leaders to provide risk mitigation assistance.
Making risks visible to your leadership gives them enough lead time to provide relief when it is needed, not weeks or months later when unmitigated risks turn into project problems.
2. Don’t forget: People can be risks, too.
I have seen many risk management plans focus entirely on things: systems that might not be ready, processes affected by outside regulatory bodies, estimates that were done in a hurry at year-end budget cycles, etc.
What project managers often fail to consider in their risk planning is that people can also be risks.
For example, let’s say your project sponsor is replaced by someone who has no experience in the subject areas of your project. This lack of experience initially will cause longer decision-making cycles as the new sponsor comes up to speed in the subject areas.
So be sure to include people risks in your risk register—they can affect your progress as much as more inanimate factors.
3. Create guiding principles for risk management.
While there may be a process in place for managing risks once they appear, quite often it is unclear to project managers when and how to escalate risks to higher levels in an organization based on their potential impact.
To create clarity and promote transparency around risk management, the best approach is to set guiding principles that govern the process. The rules should be simple and broadly communicated throughout an organization.
Examples of guiding principles include:
Declaring project risks demonstrates professional discipline that will be recognized by leadership.
A potential mitigation approach should be prepared for every identified risk.
Risks with greater potential impact need to be made visible at higher levels in the organization.
4. Use the 30/20/10 rule of thumb.
In my experience, the most frequent question asked by project managers is how many risks should be identified on a project. For example, a person might feel that a small project should have a small number of risks. But that’s not necessarily true, especially if a small project impacts a large population of people.
One risk management approach I recommend to project managers is the 30/20/10 rule, which starts with a broad slate of risks and narrows them down throughout the life of the project.
Here’s how it works: Identify risks at the beginning of the project that, if realized, would affect 30 percent of the schedule, budget or results. Midway through the project, the goal is to lower the potential impact of risks to 20 percent of the schedule, budget or results. By the end of the project, the project should carry risks containing no more than a 10 percent impact.
5. Don’t forget the bigger picture.
Project managers frequently tell me they would have finished a project on schedule, but team members were pulled into another project. Translation: another project was more important. And the strategic relevance of your project matters just as much as how you manage that project on a day-to-day basis.
To manage the risk of irrelevance, conduct an assessment on a recurring basis of how your project fits into your organization’s strategy and portfolio. Validate the relative priority of the project against other active and pending projects, and check on potential scheduling dependencies that may impact your plans, as well as any resource conflicts that may be triggered by other projects.
What techniques do you use to identify and mitigate risks on a project? If you’ve worked at an organization where flagging risks attracted negative attention from higher-ups, how did you deal with this challenge?
Seattle's Troubled Tunnel: 3 Communications Tips for Regaining the Public's Trust
Human Aspects of PM,
PM & the Economy,
PM Think About It,
Categories: Best Practices, Change Management, Communication, Complexity, Ethics, Generational PM, Government, Human Aspects of PM, Leadership, Lessons Learned, PM & the Economy, PM Think About It, Program Management, Project Delivery, Project Failure, Project Planning, Social Responsibility, Stakeholder, Strategy, Teams
One of the biggest public works projects in the United States right now has some major problems. It’s a more than $3 billion effort in Seattle, Washington to replace the Alaskan Way Viaduct, an aging elevated highway on the city’s waterfront, with a 2-mile-long tunnel. If you’ve been keeping an eye on the project, you know that the tunnel-boring machine (dubbed “Bertha”) broke down more than a year ago, creating various challenges and overruns. Public outcry is mounting.
Now, if you’re like me and believe in the power of communication to ensure that projects run more smoothly, the tunnel project has highlighted the need for more openness, better stakeholder management and speaking to your audience in understandable ways, instead of falling into buzzwords or corporate speak.
If I were working on the project right now, here are three things I would look at to regain the public’s trust and help everyone in Seattle and the state of Washington understand exactly where the project is.
1. Be willing to convey incomplete information. The project’s big challenge is that the machine built specifically for drilling the tunnel encountered a setback when it struck a metal pipe during the excavation process. Unfortunately, it took project leaders over a week to convey the extent of Bertha’s problem, the course of action and any sort of timeline to get things back on track. Since Bertha stopped working in December 2013, information has trickled out to stakeholders.
The project’s leaders could have set a much different tone early on by stating what they know and what it means to the project—along with an acknowledgement that they really aren’t 100 percent sure what the solution is, and a clear statement that they will work to provide status updates to all stakeholders as often as possible.
Instead, it’s been “hard to get straight answers,” as the Seattle radio station KUOW put it.
2. Be honest. This really goes hand in hand with the first point about having the confidence to convey information that is accurate, even if it is incomplete. The public has begun to doubt that project leaders are being honest about the tunnel’s current status and future. This is partly because when the city’s department of transportation (DOT) or the state government has updated the community about the project, they have given information that seems farfetched and is tough to believe in light of Bertha’s lack of progress.
Case in point: A DOT official recently toldSeattle’s City Council that the project was “70-percent complete.” That claim was met with a great deal of skepticism by journalists and members of the community.
The lesson for project managers is: Don’t fudge information to avoid blowback. In the long run, you are putting your project at a strategic disadvantage because you may lose funding or you may come under heavier oversight…or worse. So just explain things in an honest and forthcoming manner.
3. Be consistent in the delivery of information. A lack of consistent communications has been one of the big failings for the Seattle project team. And when there’s an information void, it will usually be filled by something you aren’t going to like. In this instance, the lack of communications has led to a real breakdown of trust.
That’s why you need to make a plan for communicating consistently with stakeholders. It should include the best ways to communicate with specific stakeholder groups, and a plan for gathering accurate, up-to-date information from the project team. To ensure timely gathering, build the consistent delivery of information into day-to-day project activities. Set a schedule of when you want your team members to communicate information to you, and hold them accountable.
In turn, you need to inform key stakeholders of when and how you’ll communicate information to them, and then stick to that plan.
In most cases, communications comes down to recognizing the importance of clarity in effective project leadership. In Seattle, you can see what a lack of a clear process can do to the trust between stakeholders and the project team. I’m confident that most unsuccessful projects began to unravel when communications stopped being clear and consistent.
What do you think?