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


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
Vivek Prakash
Christian Bisson
Rebecca Braglio
Cyndee Miller
Shobhna Raghupathy
Rex Holmlin
Roberto Toledo
Wanda Curlee

Recent Posts

Don’t Shout the Loudest—Think Ahead

Can We Use the Principles of Newspeak for Good?

The Customer Is Always Digital—So Make the Experience Right

Reality Check: Stop Being So Optimistic

PMO of the Year Winner Calls Out Executive Support

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)

How Portfolio Managers and Business Analysts Can and Should Collaborate

By Jen L. Skrabak, PMP, PfMP

Just like portfolio managers, business analysts are gaining wide acceptance as a profession. Business analysts can now earn their own PMI certification (PMI-BA) and read their own practice guide (Business Analysis for Practitioners). (Here’s a piece of cultural trivia: Did you know the latest bachelor on the reality TV show “The Bachelor” is a business analyst?)

Portfolio managers should get to know business analysts in their organization, because they can help ensure alignment and management of the portfolio to achieve the organization’s strategic goals and objectives.

What exactly do business analysts do? They, well, conduct business analysis. That’s defined as:

•identifying business needs

•eliciting, documenting and managing requirements

•recommending relevant solutions 

With this in mind, there are four major ways that portfolio managers can leverage a business analyst:

1) Develop Pipeline Opportunities

Business analysts can play a critical role in analyzing business problems and opportunities that will eventually be used to initiate projects and programs in the portfolio. Product or technology roadmaps can outline potential projects or programs that will be initiated at future points. They’re also valuable during a project because they can support proposed changes to a project scope (which will affect the overall portfolio) and ensure that the business justification for the project or program remains valid. 

Many business analysts are embedded within business areas and are critical to early identification and understanding of future opportunities or changes to the portfolio.

2) Define Needed Business Capabilities

We often think of business analysts as documenting business requirements.  Those requirements are built upon an understanding of which capabilities are needed for a particular business domain. 

Typically, capabilities are based on the goals and needs of a particular business area. Those needs may be depicted through business domain capability maps, end-to-end process flows or functional diagrams. An assessment of whether the capabilities currently exist or not becomes the basis for identifying priorities and gaps (in processes or talent). It can also be used to benchmark against other companies.

3) Develop Business Cases 

With their high-level understanding of the goals, objectives and needs of the enterprise, business analysts can assist in defining the justification for the proposed solution. The basis of a business case is the needs assessment. This process seeks to understand the underlying business problem, assess the current state and perform a gap analysis against the future state.

In addition, the proposed solution (see #4 below) is needed for high-level cost estimates that become the basis for the numerator of the ROI. The potential return (denominator of the ROI) is also based on an analysis of the impact of the solution on the current process.

4) Perform Solutions Analysis

One type of solution analysis is to assess a variety of options to go from the current state to future state. (For example, process changes vs. system implementations.) Business analysts can work with business stakeholders to define immediate solutions (quick wins that may be process changes) or longer-term solutions (new products or systems). 

Business analysis outputs provide the context to requirements analysis and solution identification for a given initiative or for long-term planning. Business analysis is often the starting point for initiating one or more projects or programs within a portfolio. The analysis is an ongoing activity within a portfolio as the business environment changes and more information becomes available, creating new competition and strategies.

How do you work with business analysts? Share your experiences and best practices in a comment below. Also, if you’re looking to learn more about how business analysts can support practitioners, check out this pmi.org webpage.

Posted by Jen Skrabak on: September 01, 2015 04:37 PM | Permalink | Comments (28)

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)

4 Tips for Selecting the Right Projects and Programs for your Portfolio

By Jen L. Skrabak, PMP, PfMP

Organizations struggle with selecting the right projects or programs for their portfolios. We see this in project success rates that haven’t increased much beyond 64 percent during the last four years, according to PMI’s Pulse of the Profession® 2015 report). We also see this in the companies that have faded from relevance or been obliterated by the pace of innovation and change—remember Blockbuster, Meryvn’s, RadioShack and BlackBerry?

The challenge is to select the right projects or programs for the right growth, placing the right bets that will pay off in the future. Here are four tips to help you do this.

1. Choose Projects and Programs You Can Sustain.

Know your organization’s current strengths and weaknesses; don’t be overly optimistic. It’s great to have stretch goals, but remember that the benefits of your project have to last.

Don’t forget about culture. Sometimes the primary reason a new project or program result doesn’t stick is that the organization’s culture wasn’t there to support it.

Organizational change management, including a defined communications and stakeholder engagement strategy, is crucial on large-scale projects and programs where hundreds if not thousands of processes may be changing in a short amount of time.

In addition, establishing a culture of project management with engaged sponsors, mature project and program management practices, and strategically aligned portfolios helps sustain projects and increase success rates.

2. Know Your Portfolio’s Upper Limit

Don’t only focus on a portfolio goal such as, “Achieve US$100 million in portfolio ROI in 2015.” Also focus on the portfolio’s upper capability.

The upper limit of your portfolio may be defined by budget, capabilities (skills or knowledge), capacity (which can be stretched through new hires or contractors) or culture (existing processes, organizational agility and appetite for change).

Define your portfolio’s upper limit and the highest resource consumption period and plan for it, rather than the initial ramp. Taking a typical adoption curve for a new project or program, your portfolio upper limit may look something like this:

3. Don’t Be Afraid to Admit Mistakes—and Fix Them Quickly

When we initiate projects and programs, and they’re not performing as expected, how quickly do we course correct, and if necessary, pull the plug? Having shorter weekly or monthly milestones and project durations is better than longer ones.

But are you equipped to act quickly when those weekly milestones are missed? How many weeks do you let a failing project go on, hoping it will get back on its feet, before ending it?

I have seen projects and programs that are not yielding the expected value being allowed to continue. Often, the sponsors still believe in the value of the project, even in the absence of metrics showing financial results. This is why setting clear financial performance metrics and monitoring them throughout development and delivery is so important: they can help project practitioners kill a project quickly if needed.

I once worked for a company that was experiencing 25 percent year-over-year growth for its products. It was a frenetic time of hiring new people, building new plants, and initiating billions of dollars in investment for new projects and programs.

However, when the U.S. Food and Drug Administration required a new warning on one of the company’s flagship products, its sales dropped 25 percent (US$2 billion annually) almost overnight. Projects and programs in flight were asked to take a 10 percent, and then 20 percent, reduction in their spending while still delivering the planned results. Planned projects and programs were suspended.

While it was difficult, the organization passed the test with flying colors. In part, this was because it didn’t spend time lamenting environmental factors but instead worked to address them—quickly.

4. Measure Your Averages

It’s not about the one big project or program success, but the successes and failures averaged over a period of time (say, three to five years). Don’t just focus on the big bets; sometimes slow and steady wins the day. 

How do you pick the right projects and programs for your portfolio?

Posted by Jen Skrabak on: April 21, 2015 01:07 PM | Permalink | Comments (8)

Sprinting a Marathon

By Conrado Morlan

It was a cold and windy morning in Chicago as I lined up among more than 40,000 runners from all over the world. I was ready to start my seventh marathon.

I had set five hours as my target finish time, and I joined a team of runners with the same goal. Before the race at the assigned corral, I met my fellow runners and the pacers who would keep us at the correct speed.

After running the first mile with the group, led by the pacers, I inevitably started to think as a project manager. I realized the race mimics an agile Scrum project, and I began to identify roles and responsibilities based on the context of the race.

The pacers played the Scrum master role. At the end of every mile, they confirmed that the runners’ cadence was right, providing feedback on speed and recommendations on hydration. At the same time, they led the stand-up, checking with every runner on how he or she was doing and if anyone would need additional support. Pacers also kept updating the backlog to ensure product increments were delivered by the runners on every sprint.

The group of runners was the self-managed development team. We had acquired the skills and abilities required to run the race after weeks of training. Our project was set to be completed in eight imaginary sprints of 3.1 miles (5 kilometers) each and would deliver the final product — the ninth sprint. It was our task to keep the cadence and burn rate constant.

As in any project, issues cropped up. On my fifth sprint, I had to make adjustments to my race plan and update my “backlog.” Around mile 15 (kilometer 24), I detected a blood stain on my left foot that kept expanding as I tried to keep my time under 11:30 per mile, so I decided to slow my pace and let the five-hour group go ahead. By mile 19 (kilometer 30), the situation was under control, and I set my new pace. But between mile 24 and 25 (kilometer 40), I had to stop at the aid station for pain reliever ointment to alleviate the discomfort of cramps in my quads.

In any race, no matter the distance, spectators and volunteers are key. They are the stakeholders of the runner’s project. Their function is to provide support along the race with signs, words of encouragement and refreshments. Spectators and volunteers’ commitment to the runners is unconditional.

An important part of the agile approach is the retrospective. For my marathon project, here’s how my retrospective would look:

What went well?

·       Enjoyed the experience of running with a pace team

·       Finished my seventh consecutive marathon and my first World Major Marathon despite a few problems

·       Improved my strength, endurance and recovery time dramatically

What didn’t go so well?

·       Not taking advantage of the resources provided at the aid stations

What have I learned?

·       Running with a pace team lessens race stress

·       The importance of listening to my “brain/body” and paying attention to its signals from the very first step

What still puzzles me?

·       After finishing seven consecutive marathons, why do I still want to run more?

·       Why do challenges pump adrenaline into project management professionals and runners?

This marathon gave me valuable lessons that will be applied at my next race, the Dallas Marathon, where I look forward to improving my performance.

Do you inevitably start thinking as a project manager when performing non-project related activities? If so, share your experiences.

Posted by Conrado Morlan on: December 10, 2014 10:34 PM | Permalink | Comments (0)

"Too bad all the people who know how to run the country are busy driving taxis and cutting hair."

- George Burns