Voices on Project Management

by , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog

RSS

View Posts By:

Cameron McGaughy
Marian Haus
Lynda Bourne
Lung-Hung Chou
Bernadine Douglas
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Roberto Toledo
Vivek Prakash
Cyndee Miller
Shobhna Raghupathy
Wanda Curlee
Rebecca Braglio
Rex Holmlin
Christian Bisson

Recent Posts

How to Spot a Top-Shelf Project Manager

3 Lessons From My First Project Manager Job

3 Strategic Resolutions For The New Year

Knowledge Management: More Than Simply Learning Lessons

Want to Start a PMO? Make Sure You Answer These Questions First

4 Tips for Delivering the Desired Business Results  

When I started as a project manager, the focus of my attention was on the mechanics of project management. This involved becoming very involved in work plans, risk/issue trackers, status reports, progress metrics and all those artifacts that form the means by which one manages a project.

What I realized after a number of years (as well as after a few hard learning experiences) was that while the mechanics of project management are important, they are merely enablers for the core activities that truly create a successful project.

I needed to think more about the successful direct and indirect business outcomes that could be created from a project. The attainment of successful business outcomes was what my stakeholders were really looking for, not necessarily the most impressive work plan or status report. This shift in focus become one of the turning points in my project management career.

So how does a project manager, in particular one early in his or her career, make the transition from executing the linear mechanics of project management to producing desired business outcomes? Well, they need to acquire the skills and behaviors that enable business success from projects— hopefully without harmful learning experiences along the way.

Here are four tips for making this transition.

1. Don’t Be Afraid of Business Processes

When I was a relatively new project manager, I spent a lot of time at my desk. This desk time was occupied with working on project management artifacts that if created perfectly would, in my mind, automatically lead to a successful project.   

A senior project manager noticed this and encouraged me to spend a fixed amount of time creating project management artifacts, with the remainder of my workweek interacting with stakeholders in the business areas. In fact, this senior project manager arranged for me to work for a few days with some of the employees that were actually executing the business processes that were to be impacted by my project. Those few days of immersion were a great learning experience that it completely changed my outlook on how to run the project.

Today, I still employ the same technique for both myself as well as fellow project managers and team members. Whether it’s working in a retail outlet helping to stock shelves, processing billing exceptions in a call center or spending time in an airliner simulator, the immersion experience is essential to understanding what makes for successful business outcomes from projects.

2.  Define Business Success Criteria

Very early in my career, I took what my stakeholders initially shared with me as business success criteria without any subsequent qualification. No surprise that some of the success criteria entailed—“just make it easy to use,” “finish testing by the end of the year” or “do whatever the senior vice president says”—didn’t really indicate a clear path to business success. 

As I grew as a project manager, I began to spend more time in the beginning of projects articulating in detail with stakeholders clear criteria for business success. This involved not only understanding current processes by immersion, but also challenging stakeholders on the methods we would use to objectively measure business success. If something cannot be objectively measured, it would be difficult to determine the success of the project.

I also allocated time in the project to build and execute the processes to measure success. By doing so, I had the capacity to create evidence of how the project benefited the business.  

3. Understand Your Industry

In my first few years as a project manager at an insurance company, I took every course on project management I could find (this pre-dated the creation of PMP certification). While I became adept at the mechanics of project management, I had no real foundation of business knowledge for the projects I was leading. 

On a recommendation of a senior project manager, I took a course on the principles of the insurance business. This course covered the terminology, core business processes and emerging industry trends. I left the course wondering how all of this was going to apply to running projects.

Within two weeks of taking this course, my supervisor passed along a compliment from my stakeholders how much more effective and efficient I was in running their project. This newfound productivity came from the ability to more easily understand the challenges that the project was intended to address. Little did I know that the industry training was a form of business process immersion.

4.  Get Comfortable With ‘Design Thinking’    

The concept of “design thinking” originated with companies finding out that while project managers thought they were achieving the desired delivery success criteria of being on time and budget, they were not really producing the desired level of business success from projects. These companies began to explore ways of changing the approach in determining business success for a project. 

Design thinking gives project managers several approaches to fully qualify the path to business success by techniques such as charting a customer journey, business process brainstorming, business case creation and creative reframing.

All of this opened my mind to going beyond the traditional boundaries of a project to ensure I was going to both define and execute to true business success.

I sometimes long for the days when I ran smaller, simpler and shorter projects whose goal was typically to finish on time and budget. I could afford to relax a bit and strive to achieve a high professional standard in the mechanics of running a project.

But as our projects become larger, more complex and longer in duration, we as project managers have to delegate some of these activities to other people, so we can get on with the business at hand of producing successful business results from projects.

These four things helped me make the transition to achieving business results on projects. What are some of the things that allow you to do the same? 

Posted by Kevin Korterud on: December 26, 2015 08:31 PM | Permalink | Comments (14)

The Best Way to Ensure Project Success? Understand and Control the Scope

By Marian Haus, PMP

There are dozens of studies about project failure. (To name just three: Standish Group’s Chaos reports, PMI’s 2013 Pulse of the Profession®: The High Cost of Low Performance and Gartner’s 2012 survey on why projects fail). There are at least as many reasons why projects fail.

Although in some cases forces external to a project can imperil its success, I am convinced that properly managing internal factors, particularly scope, is a key enabler for project success. This is because internal factors can be controlled, while external factors can merely be influenced.

Let’s take some classic reasons projects fail and tackle their root causes from a project scope management perspective.

Vague or unclear requirements and no change control—aka the never-ending scope. These are typical problems related to poor project scope management. The remedy is straightforward. Complete and clear requirements should make it to the scope; anything else poses a risk. In addition, at least a basic change management process is required to keep scope creep under control.

Lack of clear roles and responsibilities (R&R). You tailor your project team around the scope work that needs to be carried out. Because of this, you have to be clear about what your project needs to deliver. This includes product specifications, product design, implementation, integration with other related product parts, validation, delivery, etc.

If the lack of R&R clarity lies within your client organization or with an organization external to your project, then break down your project scope into specific deliverables and lay out the assumption and prerequisites for delivering them. For example, a product specification will have to be reviewed and signed off by the client, the client is expected to provide you with the validation benchmarks, etc.

A lack of R&R often results in lack of ownership and accountability of deliverables.

Underestimated timelines. This can happen especially if estimations are done based on insufficient information or when the scope is not well understood. Estimates are consequently rough, based on previous experience, approximations and assumptions. If conditions are changing during the project lifecycle, this can lead to time or budget overruns.

Unclear and/or unrealistic expectations. This is often related to the project scope. Your project team might be unclear about what it is supposed to deliver or what level of quality and maturity your deliverable will have to pass to meet the acceptance criteria. In other cases, the team might be unclear on how the delivery of your project scope will impact the receiving organization.

Project complexity. This relates mainly to the failure to break down a large scope into more manageable pieces and deliverables. If the list of deliverables is not clear, the sequence in which these are to be produced will not be determined. If the deliverables’ relation to each other isn’t clear, then team members will just be busy delivering something, sometime, for some level of effort. This leads to missing the project goal or ending up with time or budget overruns.

A well-understood and executed scope brings you a huge step closer to finishing your project successfully.

What is your experience with managing project scopes? What key factors, other than scope, do you see as enablers for project success?

Posted by Marian Haus on: October 19, 2015 02:50 PM | Permalink | Comments (16)

5 Things Unsuccessful Portfolio Managers Do

By Jen Skrabak, PMP, PfMP

I am amazed that so many projects and programs (and by extension, portfolios) are still so challenged. Forty-four percent of projects are unsuccessful, and we waste $109 million for each $1 billion in project expenditures, according to the 2015 edition of PMI’s Pulse of the Profession.

One solution that the report identifies is mature portfolio management processes. With that in mind, I’ve come up with a list of five things that unsuccessful portfolio managers do—and what they should focus on doing instead.

1.  Worry about things they can’t change.

Unsuccessful portfolio managers worry about the past or dwell on problems outside their immediate influence. Successful portfolio managers learn from the past and move on. Sometimes, failures turn into lessons that create the foundation for future growth and opportunity.

Portfolio managers should stay focused on what can we influence, negotiate and communicate, as well as what we can start, stop and sustain. Every month or quarter, assess the processes, programs and projects in your span of control. Decide which to start, stop and sustain, and develop action plans around those decisions (including dates, resources required and collaborators).

2.  Give up when things get too hard.

It may be easy to throw in the towel when conditions become challenging. But the hallmark of a good portfolio manager is the ability to find solutions.

Sometimes, our immediate reaction to a proposal is to think the timeframes or goals are not possible. However, when we get the team together to focus on what can be done, we come up with creative solutions. It’s necessary to gather the facts and do the analysis instead of jumping to conclusions.

3.  Set unattainable goals.

There’s a difference between a stretch goal and an impossible one. Sometimes, projects or programs don’t start off as unattainable (see #2 above) or undoable, but they become so.

Although we may be good at starting projects or programs, there’s not enough emphasis on stopping them. The environment (internal or external) may have changed, key resources may no longer be available, organizational priorities may have shifted, or the business buy-in might take too long. Rather than calling attention to the situation and recommending a “no go,” unsuccessful portfolio managers tend to press on with blinders. This wastes time and resources.

Once I was managing a $500 million portfolio of international expansion programs and projects. The portfolio sponsor told me, “I want to know if we’re falling off the cliff.” Although we hope our programs or projects never get to that point, his words did clearly specify the role I was supposed to play.

4.  Stay in your comfort zone.

It’s easy to create a portfolio in which the potential for risk and failure is low. But that means we may be missing out on opportunities for innovation or great returns. Advocating change in your portfolio requires taking calculated risks that you can learn from or will pay off in the longer term. The successful portfolio manager will advocate taking good risks (aka opportunities) instead of blindly going forward with bad risks.

Taking advantage of opportunities is the key to transformation and reinvention. It’s essential to any organization that wants to survive long-term. For example, who could’ve predicted just a few years ago that Amazon, Netflix and even YouTube would become rivals to TV and movie studios in providing original entertainment? This required calculated risk taking.

5.  Forget about balance.

Balance is important, whether it’s balancing your portfolio or balancing your work and your life. If you’re not performing your best because you’re not taking care of yourself, it’s going to affect your portfolio. Especially with technology blending our work and personal time, it’s sometimes hard to think about balance. One survey showed that we’re checking our phones up to 150 times per day. But remember the basics: eat well, exercise, take time to de-stress, and set aside time for yourself, family and friends. 

What do you notice unsuccessful portfolio managers do, and what would you recommend instead? Please share your thoughts in the comments.

Posted by Jen Skrabak on: October 10, 2015 11:12 PM | Permalink | Comments (14)

Agility vs. SOPs: Finding the Right Balance

By Lynda Bourne

Organizational agility is being promoted as the silver bullet to create value and eliminate project failures. However, decades of research show that factors like methodologies and standard operating procedures (SOPs) are essential underpinnings of consistent success.

Are these mutually exclusive propositions? Or is there a more subtle answer to this apparent contradiction?

First a bit of background: There’s decades of research looking at various maturity models, ranging from the old CMM (now CMMI) to PMI’s OPM3. The consistent findings are that investing in creating organizational maturity demonstrates a strong return on investment. Developing and using a pragmatic methodology suited to the needs of the organization reduces failure, increases value generation, and outcomes become more consistent and predictable. These findings are supported with studies in the quality arena, including Six Sigma, which consistently show that good SOPs reduce undesirable variability and enhance quality.

But given that every methodology consists of a series of SOPs, where’s the room for agile? In fact, you can get the best of both worlds by embedding organizational agility into your procedures, methodologies and management.  

Solid Standard Operating Procedures

Getting your standard operating procedures right is a good starting point. SOPs should define and assist project teams in the performance of standard processes. SOPs also should provide templates, guidelines and other elements that make doing the task easier and quicker.

Key success factors for SOPs are:

  • Team members need to know there is a SOP and when to apply it
  • SOPs need to be easy to locate
  • The SOP must be in the right format and meaningful
  • The information must be accurate and up-to-date
  • The SOP must reflect current work practices: the what, how and why
  • The SOP must be lean, light and scalable so it can be used in different circumstances
  • The SOP must demonstrate a clear purpose and benefit (saving time, quality, safety, etc.)
  • Leaders must be seen using the SOP
  • SOPs must be consistent across the organization
  • Team members must have the opportunity to improve the SOP, embedding lessons learned and agility in the process

The enemy of useful SOPs is a dictatorial unit focused on imposing its view of how work should be performed in a bureaucratic and dogmatic way.

Flexible Methodologies

Methodologies combine various SOPs and other requirements into a framework focused on achieving project success. A good methodology must also be lean, light and scalable so it is fit for use in different circumstances. Every project undertaken by an organization is by definition unique, therefore the methodology used by the organization must allow appropriate flexibility—one size does not fit all, ever! 

The PMBOK® Guide describes it this way: “Good practice does not mean that the knowledge described should always be applied uniformly to all projects; the organization and/or the project management team is responsible for determining what is appropriate for any given project.” A good methodology incorporates agility by including processes for scaling and adjusting the methodology to fit each project.

Management Agility

The final element in blending agility with sensible processes is an agile approach to management. But agile doesn’t mean anarchy. It means the flexible application of the right processes to achieve success.

The so-called military doctrine of command and control is outdated. The rigid, process-oriented concept was replaced by the idea of “auftragstaktik,” or directive command, in the Prussian army following its defeat by Napoleon at the battles of Jena and Auerstedt in 1806.

The core concept of auftragstaktik is “bounded initiative.” Provided people within the organization have proper training and the organizational culture is strong, the leader’s role is to clearly outline his/her intentions and rationale. Subordinate personnel can then formulate their own plan of action for the tasks they are allocated and design appropriate responses to achieve the leader’s objectives based on their understanding of the actual situation.

But the process is not random. SOPs define how each specific task should be accomplished, and bounded initiative allows team members to optimize the SOP for the specific circumstances to best support the leader’s overall intent.

Helmuth von Moltke, chief of staff of the Prussian army for 30 years, believed in detailed planning and rigorous preparation. But he also accepted that change was inevitable, famously saying, No plan of operations extends with any certainty beyond the first contact with the main hostile force.”

Projects are no different! Both the methodology and the project management plan need to encourage bounded agility to lock in opportunities and mitigate problems. Effective military leaders were doing this more than 150 years before the Agile Manifesto was published. It’s time for project management to catch up!

How much bounded initiative does your methodology allow?

Posted by Lynda Bourne on: October 05, 2015 11:37 PM | Permalink | Comments (14)

The 3 Things That Transcend All Project Approaches

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 dave@davewakeman.com! 

Posted by David Wakeman on: August 30, 2015 09:49 PM | Permalink | Comments (11)
ADVERTISEMENTS

Some editors are failed writers, but so are most writers.

- T. S. Eliot

ADVERTISEMENT

Sponsors