Business Transformation in Disguise
By Jess Tayel
In the quest to uplift capabilities, better serve customers, improve the bottom line or acquire market share, organizations rely on a mix of projects and programs.
Some projects are scored as critical and complex. Some organizations have a clear and defined scoring system of what is critical and what is not, while others settle for a subjective measure.
But even after you’ve determined a project is critical, there’s more to consider.
Is it Change or Transformation?
When it comes to big, critical projects, ask yourself: Are you delivering a change initiative or a business transformation initiative?
Why is this distinction important? Because they both have different characteristics that dictate how they should be brought to life.
Change initiatives execute a defined set of projects or initiatives that may or may not impact how things work across the entire organization. Examples include introducing a new payroll system, moving into a centralized shared services model or executing an office move.
Business transformation, however, is a portfolio of initiatives that have a high level of interdependencies, leading to change across the organization. They’re focused not just on execution but also on reinventing and discovering a new or a revised business model. That model is based on a significant business outcome that will determine the future of the organization.
With that in mind, business transformation is more unpredictable and iterative, and it’s about a substantial change in mindset and ways of doing business. The “how” may not be as defined as it is in change initiatives, which means you need to try different methods and be more experimental.
Set Your Organization up for Success
Because of these distinctions, business transformation should never start with finding a solution, i.e., bring in this technology, hire this firm, change model X to Y. It should instead focus on the following:
You may say that these questions can be part of the initiation phase. But in my 20 years of experience around the globe, I have rarely seen the above steps executed diligently from a customer centricity point of view before teams start to dig for a solution.
That said, time spent clearly articulating those elements is well spent and directly contributes to the success of the transformation, while reducing rework and change fatigue. It’s like spending time to sharpen your saw before starting to cut the tree.
In my next post, I will talk more about what is required from the leadership and internal transformation teams to facilitate and create success.
Feel free to comment below and send feedback; I would love to hear about your experiences with business transformation
by Kevin Korterud
Once upon a time, projects were just projects. They were simple, had small teams and quite often finished on time. Projects were viewed as a path to operational improvements that reduce manual labor and free up people for other tasks.
As time marched on, the notion of a project began to increase in scale and complexity. Technology projects, for example, began as modest hardware and software initiatives. Over time, the technology project landscape has changed to include network, servers and cloud infrastructure. Software projects began growing into systems, software packages and complete end-to-end solutions.
As the quantity and business focus of project work increased, they became packaged into programs. Programs were created to help orchestrate myriad projects into cohesive outcomes. These were governed by an expanding slate of waterfall methods designed to both enable and oversee delivery.
With the advent of agile, a different form and pace emerged. Product delivery moved toward quicker and more frequent outputs, with delivery cadence driven by what an organization believed was best for customers and consumers.
Today, organizations have a delivery ecosystem of project, program and product delivery work based on internal and external dynamics. As the ecosystem changes over time, the balance of projects, programs and products does as well.
With project, program and product delivery all moving in different directions and at different speeds, how can an organization prevent these efforts from crashing into each other? Here is an approach I follow to help define, oversee and enhance the natural delivery ecosystem:
First, ensure that definitions are in place. These should be clear and concise portrayals of the work to be performed. Having these definitions commonly understood will go a long way in matching the correct policies, processes, controls and people to the form of work.
Here are some sample definitions:
These definitions also serve to identify the portfolio proportion of these different types of work, which helps determine the right people and supporting structures for success.
The ecosystem can change and flow to meet the needs of organizations, market forces, suppliers and people. Given this ebb and flow, one practical reality of this ecosystem is that any one form of project, program and product work cannot exist as 100% of the work.
2. Govern the Ecosystem
Any delivery ecosystem left to its own resorts will result in chaos with teams having different perceptions of how project, program and product delivery should be executed. This chaos will result in delays, additional costs and sometimes stalemates as teams negotiate over the execution of work efforts.
There needs to be balancing forces in place that help direct delivery. A delivery ecosystem governance model sets the boundaries for delivery work from ideation into formation and through execution. The governance model implements policies, processes and enabling artifacts that create predictable and repeatable attainment of desired results. This governance model is typically overseen by an enterprise delivery management office.
For example, one process within this model sets the venue to identify, confirm and release for execution the proper delivery process for a type of work. A portfolio review board based on input from the sponsor would analyze the characteristics of the work and determine whether it is a project, program or product. The outcomes from this portfolio review board promote consistency, ensure impartiality and avoid costly re-work due to poor decision-making.
Even an effective delivery ecosystem needs to have a “tune-up” every once in a while. As changes in business strategy, support for new regulations, market expansions and technical innovations come into play, the delivery ecosystem needs to change accordingly. These drive the need for a function to continuously harmonize and improve the delivery ecosystem. An EDMO will be the primary vehicle to both harmonize and improve the delivery ecosystem within an organization.
Improvements can include initiatives to reduce mobilization time, avoid resource contention and improve supplier integration. These initiatives are universal in nature and can be consistently applied to improve project, program and product delivery.
With the increased complexity of work and differing approaches for projects, programs and products, you need a means of harmonization to prevent misalignments, conflicts and collisions between work efforts. Harmonization processes can include release, dependency, data integration and test environment management.
Embrace the New Normal
Organizations need to recognize and embrace the different forms of delivery that are now the new normal. By adopting a structured approach to the definition, oversight and enablement of projects, programs and products, they can be delivered in a synergistic manner to lower costs while improving time to market and quality.
How do you balance the project, program and product initiatives at your company to avoid weather problems?
By Wanda Curlee
Portfolio management is slowly being adopted by corporations. Or is it? I am speaking from my perspective, which admittedly is narrow, but I wonder if company leadership has what it takes.
I have worked at different organizations—from retail and legal to medical and government—and they all say yes, they are ready to do the hard work. But when you try to start developing requirements or even do a gap analysis, there are many reasons why it doesn’t happen: leadership is not in sync, resources aren’t available or there’s not an appetite for change. Or even worse, there is only one person who champions the cause, and he or she does not have the political momentum to push the effort.
The pushback can be major or minor. Leadership might say they had no idea you would need their people to develop the processes, templates and tools. Or leadership might ask if the company can just get a tool instead? There are solutions to all of these points, but leadership may not want to hear them.
So, how do you get over these hurdles?
For some, it’s a matter of providing training and knowledge. Leadership may truly have no idea what portfolio management is. In their eyes, it’s simply knowing what all the projects are in their area. That is one aspect, but there are several steps before you even get to that spot.
For instance, will you look at all projects in the organization, or only those of a certain budgetary value or length? Perhaps a combination of both?
Then there is the question of how to slice and dice the projects.
To slice and dice, you need to understand how to relate projects to strategy. Does your organization meet several of the corporate strategies or only one? If you have a project that is not allocated against a corporate strategy or sub-strategy, then why are you doing it? It’s taking resources and budget away from projects that do have strategic value. Even operational projects, such as upgrading software to a new version or implementing new enterprise software, need to map to a strategy.
For example, imagine your company has a strategy to increase sales by 20 percent in three years. The current sales tool has received well-deserved criticisms, and the tool is too small for the current sales volume. Implementing a new sales tool probably makes sense. However, the new tool would require the company to be running the latest version of operating software. The portfolio manager would recognize this, along with IT, and the portfolio manager would argue the case that these are interrelated. The opportunity exists here to make these two software projects and all the peripheral workstreams, such as training, into a program.
Do you have what it takes to push portfolio management forward? Or will you just succumb to pushback?
Don’t be afraid to speak up. If project portfolio managers don’t advocate for the correct way to do project portfolio management, organizations will suffer in the long run. The wrong way to do something is expensive and not beneficial.
Don’t let your company fall into that trap.
What experiences have you had when pushing portfolio management forward? Please share below.
By Jen Skrabak, PMP, PfMP
Over nearly two decades in project management, I’ve learned a number of strategies to make my voice heard and advance in my career. Much of that success has come by “leaning in,” as Sheryl Sandberg advocates.
As a woman in project management, I believe the following are key:
International Women’s Day is March 8, and this year’s theme is #BalanceforBetter. Please share your thoughts on how we celebrate the achievement of women while we continue to strive for balance for women socially, economically and culturally around the world.
By Jen Skrabak, PfMP, PMP
As a woman who’s worked for the past 18-plus years in project, program and portfolio management, as well as building and leading enterprise project management offices for Fortune 500 companies, I wanted to address the topic of women in project management.
In the United States, women hold 38 percent of manager roles, according to a study conducted by McKinsey in partnership with LeanIn.Org. And while women have made gains in some STEM fields, particularly healthcare and life sciences, they are underrepresented in many others. U.S. women hold 25 percent of computer jobs, and just 14 percent of those in engineering, according to the Pew Research Center.
In project management, as in other professions, women earn less than men. For project managers in the United States, men earn an average US$11,000 more annually than women, according to PMI’s Earning Power: Project Management Salary Survey.
Historically, women have been pigeonholed in project administrative or project coordination roles instead of project management roles, and the key question is “Why?”
We’ve all heard that we need to “think differently,” and as Sheryl Sandberg advocated in her book, Lean In: Women, Work, and the Will to Lead, women need to raise their hands, project confidence, be at the table and physically lean in to make themselves heard. The dictionary definition of “lean in” means to press into something. So when faced with an overwhelming force such as wind, you need to lean toward the force rather than away in order to not be blown away.
“Lean in” can be a metaphor for asserting yourself as a leader in project management. As women, we may be held back by self-doubt, our speaking voice or body language that conveys a lack of self-confidence. The advice here is not limited to women; people of color can “lean in,” too.
There are three key cognitive biases that may hold women back in project management. The key is to recognize that these exist, and work to build awareness while overcoming them:
By understanding and recognizing these biases, we can work to defeat them. I’ll explore these topics more in my next post, which will coincide with International Women’s Day on March 8. How do you combat biases in the workplace?