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 Ramiro Rodrigues
A great deal of effort is often put into a project kick-off meeting—so why isn’t that visibility just as important on the other end of the project?
What is a project closing party?
A project closing party is an event that intends to provide visibility and recognition to the main professionals involved in a completed project. Obviously, there is no sense in celebrating a project that got aborted or that didn’t reach its main goals and targets. So, we are talking about those projects that managed to get to end with the best combination of its intended results.
Within this proposal, it is reasonable to say that what will drive the size of the closing event will be the size (and budget) of the specific project, since it is necessary to achieve coherence between these variables.
What are the benefits?
I see two arguments for hosting these events at the end of a project—one strategic and one motivational.
On the strategic side, a closing party brings visibility to the executing organization (and, if applicable, the hiring organization) that the project has reached its predicted goals. It will help to reinforce to those at the strategic level of the organization that the team is capable and reliable.
From a motivational standpoint, these events will help recognize the efforts of the project team.
How should they be executed?
If you think a closing event could benefit your project efforts, here are some tips to abide by:
Done well, events like a project closing party can have positive repercussions on your next projects.
Do you regularly host or attend closing events at the end of your projects? I’d love to hear your thoughts!
As a project manager, there’s perhaps nothing better than starting a new project. With it comes a fresh start and the promise of a successful conclusion. To me, it’s akin to starting a new year in school with new notebooks, where nothing has been written to spoil the fresh sheets of paper.
However, as we become more experienced as project managers, we’re called on more and more to assume control of a project already in motion. This might be triggered by a happy event, such as a promotion for the existing project manager, or a less-than-happy situation, such as a lack of progress on the project.
Assuming responsibility for a project that has already launched is a lot different than starting from the beginning. You won’t have the benefit of starting with a clean sheet of paper, and there will be things you need to do—and undo.
Here are three tips I always follow when assuming control of an existing project:
1. Assume Nothing
When starting a new project, you have the opportunity to perform mobilization and initiation activities to effectively set the project on a path to success. In addition, there are some early checkpoints where you can perform structured control actions to further assure the proper trajectory of the project.
While the existing project status reports can show the assumed disposition of a project, they may not reveal essential missing activities needed for project success. For example, an existing project might not have had the benefit of a thorough mobilization and initiation effort to properly set its course. In addition, there may be hidden or under-mitigated risks, emerging issues, stakeholder challenges and hidden dependencies that have not yet come to light.
When taking over an existing project, the first thing I do is review it in the same way I would a new project. Introducing a pause in project activities to perform a “soft reset” allows both confirmation of assumptions and validation of project progress.
In addition, this activity can reveal unseen factors that put the current project position in doubt. This is a good time to reforecast the remaining work. By assuming nothing about the project, the “soft reset” serves as a basis to properly transition the project towards success.
2. Match the Team to the Realistic Remaining Work
One of the most important facets of a soft reset is reforecasting the amount of remaining work. Use the existing forecast as a foundation for considering other factors that may influence the future progress of the project. These may include effort, scheduling conflicts (e.g., year-end holidays), upcoming business process changes and technology-readiness dependencies.
From the reforecast, compare these factors against the capacity and capabilities of the existing project team. Review whether you have the requisite skills and team members available for each phase of the project. In addition, consider the availability of key resources who cannot be readily substituted in case they are not able to work on the project. This examination of project resources by phase should include not only individual team members, but also team leads and third-party suppliers.
3. Engage More Frequently With the Most Accountable Stakeholder
While there are many inorganic components of a project, such as deliverables and status reports, often the most critical components revolve around the organic nature of people. Having strong executive sponsorship, a structured governance engagement model and open communication all enable project success.
When you are introduced as the new project manager on an existing effort, some change management work will need to be done to ensure a smooth transition.
Given the myriad stakeholders involved in a project, who should you start with? The typical consideration is to start with the most senior leadership stakeholder, who is typically also the project sponsor.
I think, however, a better place to start is with the most accountable stakeholder. This would be the person who after the project is implemented would manage the new solution to achieve the project objectives. In addition, this person would likely have the greatest knowledge of requirements and implementation considerations, which would be valuable to your soft reset.
Set Your Team Up for Success
Assuming control of an existing project should have that same level of attention to detail and precision. Now that you are leading this existing project, be sure to consider the factors shared above that confidently allow you to say, “I have the controls.”
When assuming existing projects, what sort of activities do you perform as part of a transition? I’d welcome other thoughts to help make us all better project managers.
Make it or break it!
In the world of Business Transformation (BT), project management plays a critical part in the successful delivery of the business transformation programs to an extend where I can say it is a “Make it or Break it”
And why is that?
Imagine a school music play and the effort required to coordinate everything to get it done successfully. Of course, there is a lot of planning, coordination and execution that goes into it to produce a high quality school play
Now imagine an orchestra and the effort required to get this done successfully. In essence and to the inexperienced eye, the tasks may be similar but the effort and complexity are just a different ball game altogether
This is the same thing when it comes to managing a non-BT project and a BT project. The main tasks of initiation, planning, execution, monitoring and closing may look the same on the surface but underneath the skeleton, is a different level of complexity
Having said that, BT project management requires a different calibre of project managers to help get the beast out of the door while achieving business outcomes
To be on the same page, let’s define what business transformation is. Business transformation is a significant change that an organization goes through impacting its people, process and/or technology. The change is usually a complex one with long term business outcomes to be achieved
Project management becomes the core part of delivering the business transformation and ensure that business outcomes are achieved. The calibre of the BT project manager is therefore a lot more complex and at a higher level of maturity. Below are the key characteristics for a successful business transformation project manager
Exceptional Business Acumen
Visionary and can see beyond the short term goals
Can see different angles and prospective
Diversified skill set
Knows and understands failure
Knows the job and acts beyond it