In our prior blog post we suggested some fundamental concepts on how to change the game to focus on winning performance for a whole portfolio, not just individual
We also suggested that making effective tradeoffs calls for continuous adjustments with an adaptive portfolio management approach. We believe a continuous planning and execution cycle delivers advantage. In this blog we’ll look at the impact of discontinuous vs. continuous planning processes on portfolio success.
In our first installment we referred to the book Playing To Win by A.G. Lafley and Roger L. Martin. The authors contend that most teams and even organizations are too often simply “Playing to Play” – trying to not fail. “Playing to Win,” in contrast, forces teams and organizations to understand what it would take to succeed, not just ‘not fail.’ Let’s use this “Play to Play” and “Play to Win” metaphor to examine some alternative approaches in software portfolio management.
Projects are discontinuous by the traditional definition
A fundamental concept from the Project Management Institute is that “Projects are temporary in nature and have a beginning and end date”. This concept results in discontinuous planning and execution cycles where project success focuses on delivering predefined deliverables by the given end date.
Playing to Play
Much planning goes into determining a realistic schedule and budget. If issues arise, the typical action is to make corrections to align with the original plan. But the original plan was based on the least information. In engaging the actual content, more knowledge is gained but only factored into the plan as it relates to meeting the original deliverables. Beyond a brief User Acceptance Test round in which new ideas are rejected as out of scope, little time is devoted to understanding and adapting to current needs. Eventually the bits are moved to production. We consider it “finished” and move on!
While the project may be declared a success, the users’ current needs for the software lag significantly behind the fulfillment of those needs because now some other project is currently filling the pipeline for development work.
Playing to Win
Software is rarely “finished.” Using it will inevitably lead to better ideas about how to improve it. Plans need continual updates and adjustments based on fast feedback from the actual beneficiaries of the effort – the users.
The best time to capitalize on those ideas is when they are still “fresh”. A continuous planning and execution cycle is called for. It is often too late if another six months is needed to plan ramp up a project for the next version. A continuous approach also eliminates waste in ramping up and ramping down projects, then ramping up again.
While Projects are useful as a unit of funding and financial control, borrowing the life cycle concept from product management can be helpful in making planning more continuous. Consider what life cycle stage the current project is intended to support and start planning a project for the next stage before the current project is complete. In the early or mid-life stages an immediate follow on project is often justified. Using a life cycle concept also encourages looking at the cost and benefit equation for the entire life cycle, not just the initial project to create an asset in the first place. (We’ll explore product life cycles further in the next article in this series.)
Project teams are not accountable for winning results
Projects are organized and staffed with the people needed for only the duration of the project. “A project has an organization structure” and a “project has resources”. Project teams are organized to play, not to win, because they are only accountable for what happens between the beginning and end dates.
Playing to Play
Beginning dates are often dictated by prior projects’ completion dates; and end dates are often dictated by business ultimatum. In our experience with IT groups, business results are not often a part of the project’s defined outcomes. Disbanding teams after a project’s end date often in itself leads to “play to play” results. Positive results are often not visible until after the team has been disbanded.
Playing to Win
When teams are aligned to business objectives, they can better apply their expertise to determine how to Play to Win. This requires that IT have a seat at the organization’s strategic planning table. As IT grows from a back-stage player to supporting front-line sales, marketing, and fulfillment functions, it is critical to shorten the time and the distance between need and solution. The key is a dedicated, engaged team of business and IT people focused on, and accountable for, a current business objective.
Ideally, when that objective is reached, the same team can take on the next objective for that business group. This builds productive and valuable relationships in two ways. First, the team builds valuable business relationships and context that is often lost when teams are split up after a project. Second, the team builds working relationships within the team that result in higher productivity than if teams are split up and reassigned to new projects. Projects can still be used as funding units, but don’t form new teams for each new project.
The annual plan overrides business rhythms and realities
One of the biggest challenges to overcome is the annual plan which is often driven entirely by budgeting. After all the wrangling, the annual plan for IT is often disrupted within weeks of the new year’s beginning. Why? Because projects planned to finish by the end of the previous year refuse to cooperate and be done on time!
Playing to Play
Annual planning results in sub-par Play to Play results when people expect to just execute as planned for a whole year. Of course this rarely happens. Financial conditions may change or new customer opportunities may drive different priorities.
This urge to comply with plans that were made with so much effort perpetuates the contention for project resources, the compulsion to cut valuable functionality to meet schedules, and results in much less value delivery. The project itself becomes the focus, not the desired impact on the business.
Playing to Win
A more continuous planning process for portfolio management supports Playing to Win by monitoring the feedback from what the teams are learning as they tackle each business objective. How often should you revisit and adjust? Look past the annual budget cycle and try to discover the natural rhythm of your business. Do your customers make seasonal demands? Are there significant events that repeat from year to year? Changing the timing of your planning and portfolio management decision making to be more frequent and flexible can drastically improve the impact of each team’s efforts.
When teams are aligned to business objectives, the entire “project” construct takes on a different form. Rather than a “start-stop” mentality, the team shifts to a more continuous-flow value delivery perspective. If the business objective is met, the team is finished. If the business objective changes, the team adapts. If the business objective is dropped, the team can pursue a new objective.
Conclusion: Playing to win demands continuous updates and adjustments
Given the rate of change in business today, following the pre-defined plan and just keeping each project “on-track” results in Playing to Play results and won’t get winning results as often. In this blog we have suggested some ideas for moving from a discontinuous to more continuous planning for Playing to Win results.
- Software is rarely “finished.” Capitalize on improvement ideas from users while they are still “fresh”
- Consider entire life cycle to make planning more continuous
- Align teams to business objectives not just deliverables
- Build teams that last beyond the duration of a project and include relevant business expertise
- Monitor the feedback from what the teams are learning
- Leverage the natural rhythm of your business
- Change planning and portfolio management decision making to be more frequent and flexible
Playing to Win challenges some well-established management practices such as the traditional definitions of a project and annual budgeting processes. It also demands some mindset changes, such as fostering business expertise and relationships, shift to continuous-flow value delivery , and creating “safe to fail” environments.
In the next installment, we’ll look at the differences in managing project portfolios and product portfolios, and examine product lifecycle concepts for applicability in project portfolios.