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?
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.
Cinephiles and regular movie-goers know who Sir Philip Anthony Hopkins is. Sir Anthony is a Welsh actor of film, stage and television, considered to be one of the greatest living actors.
Your journey as a project management practitioner may be similar to Sir Anthony's journey as an actor. You may have to play different roles in projects and might gained recognition for your work. As your journey continues, you may be looking for the next stop that may lead you to explore other project management disciplines, like agile -- and, in particular, the role of an agile scrum master.
From Stage to Movie Set
Versatility is a virtue of all great actors. Though Sir Anthony has experience as a stage actor, acting for a film is quite different. As a stage actor, Sir Anthony had to undergo many rehearsal hours, and experienced a specific, tight-knit team of actors and staff. Lighting and environment are essential for the performance and there is no room for error in every live show. A theatrical play delivers a well-defined "product" that may resemble what agilists call a "traditional project" under waterfall methodology. As a project manager, you "manage the stage" of the project, meeting the stakeholders' pre-defined requirements and applying your skills supported by the project team. Your project will deliver the product or service it was intended for.
But on the film set, Sir Anthony likely needed to be more flexible, since a scene may require several takes until the director is pleased. The film set is more dynamic: different locations; a different type of crew; the addition or removal of stunts, etc. The phases of a motion picture-making -- pre-production, principal cinematography and post-production -- are similar to sprints in an agile environment.
Sir Anthony makes transferring acting skills from stage to the film set seem easy. But like him, you also have transferrable skills: you can communicate, influence, orchestrate and remove roadblocks. You can use these talents to help you adjust to the new project environment.
From Hannibal to Odin
While Sir Anthony has occupied diverse roles -- from Richard Nixon (Nixon, 1995) to Odin (Thor, 2011) -- he's been successful because he's always prepared properly, trained to correctly represent the character and depended on his foundation as an actor (whatever the media).
As a project practitioner, you are likely familiar with PMI's A Guide to the Project Management Body of Knowledge (PMBOK® Guide)--Fifth Edition, tools and techniques; best practices; and project methodology of the company or customer you work for. Those elements complement your preparation and training as a project manager -- and lay the foundation to explore and learn new methodologies like agile.
What is your experience as a project management practitioner transitioning to scrum master?
As agile matures, it's being employed at the program level by larger teams, many of which are broken down into groups. How must agile evolve to match these growing needs? In this first of two posts, we will look at some of the key objectives of the agile approaches designed for large-scale projects.
Scott Ambler's Disciplined Agile Delivery and Dean Leffingwell's Scaled Agile Framework are two such approaches. These in particular reevaluate some concepts from the IBM Rational Unified Process framework. Among the most useful concepts shared by all three is the opportunity for teams to balance upfront planning needs while preserving agile's ability to refine the plan based on empirical observation of real results. All also speak more to what architectural underpinnings are necessary to give larger teams a firm foundation:
In larger teams, agile approaches -- such as the feedback afforded by iterations in Scrum -- remain popular, as do the technical practices centered around quality. Lean principles used by smaller agile teams remain important to reduce wait time, optimize the entire system and balance flow among teams. But the frameworks mentioned above also add a fourth dimension: synchronized relationships among agile teams. In particular, aligning teams so their sprints end at the same time is useful, because it facilitates the release of the product.
So what's different for large teams trying to use agile methods? First, overall investment governance becomes all the more important. Larger projects require more preparation to justify the greater levels of funding. They also may have more complicated dependencies among teams. Organizations will need to find a way to allocate effort between work in their portfolio of projects. This includes not only features, but also infrastructure work and nonfunctional requirements. And organizations should also use investment gate models to ensure funds are invested wisely.
Second, technical architecture is also very important. In smaller agile teams, people may experiment first and then evolve guidelines and patterns. But in larger teams, overall design and architecture plays a leading role so as to better coordinate among teams. System teams, or people who work on supporting teams creating features, also become important as the demand for a shared infrastructure increases.
Finally, metrics quickly become important. New metrics -- designed specifically for larger teams -- provide a holistic view of the overall health of the large team, and also help gather and assemble data for the smaller groups within. This allows organizational leaders to see, at a glance, where the overall program stands, so they can make broad project decisions with wide impact.
These general principles guide many methods to scale agile from teams of seven to 100 members. In my next post, we will look at some specific practices to enable large teams to find the benefits of agile.
What do you think are the fundamental principles of scaling agile?
When we're first introduced to agile, we learn so many steps and procedures that it's easy to forget why they're useful. The exam to become a PMI Agile Certified Practitioner (PMI-ACP)® asks questions on practices -- and it also does a good job of testing your knowledge of the value behind them.
Yet knowing the "why" behind a practice helps you keep close to the core values of agile when handling unforeseen situations.
1. We graph, but why? The concepts of big visible indicators or information radiators deliver two benefits: a self-organized team and risk reduction. Graphing helps the team react more quickly, since everyone sees the same data at once, rather than one leader looking at the data and then issuing decisions.
When graphs illustrate the risk of falling behind, the team is able to take action. Whether you are using Scrum or Extreme Programming (XP), visible charts are crucial to understanding your rate of work. Remember that completing charts is as important as knowing how to interpret the message they present.
2. We have a task board, but why? A task board shows a list of work in at least three columns: "To Do," "In Progress" and "Done." Some teams have paper notes, or the electronic equivalent, that march across the board as work progresses. But not every team asks the all-important question: "Are we juggling too much at the same time?"
Visual task boards make it easier to see when things start falling behind. Don't just watch the tasks move across the task board. If a traffic jam develops in the middle of the board, ask why.
For example, lean and Kanban methods visually highlight the need to limit the work "in progress," or how many tasks your team is juggling. You can do the same amount of work, but focus and finish a few at a time. This improves your cycle time and surfaces any risks earlier.
3. We have a process coach, but why? In both Scrum and XP, there is a role on the team tasked with knowing the process and making it perform as advertised. In the case of Scrum, that is the Scrum master's job. In the case of XP, it's the coach's job.
Process coaches are instrumental in fostering your team's ability to self-organize rather than relying on one leader to delegate work. If you have a coach on your team spending more time assigning work than mentoring others to use a process, then your team's ability to self-organize -- and foster nimble work and cross-functional roles -- suffers.
4. We communicate openly, but why is this important? It's easy to avoid conflict and let disagreements stand, but agile relies on surfacing issues so they can be dealt with as early as possible. The social contract of the agile team must be "Bad news is good" and "We're all in it together."
The only bad issue is one that doesn't get raised. If you communicate but don't mention controversial points, then you're veering from agile values -- and perhaps growing less agile for it.
What other agile values are important to you and your teams?