Much has been said about the impact of digital transformation in the marketplace, and there is no question that this transformation is key to ongoing success and longevity for many businesses. This is the second in a series of posts created to address the crucial aspects of performing a successful digital transformation.
Not long ago I was a front row spectator to the challenges of scope in a digital transformation effort. My customer, we can call him ‘Jack’, sat with his head in his hands and was clearly upset.
To paraphrase: ‘The budget to do this project is X and the business is demanding features that are 2X—what am I going to do?’ Clearly managing scope is a major project from both a traditional PM perspective as well as organizationally.
Scope saves budget and builds consensus
There are a ton of source documents online about how to build a statement of work and define scope. Most of these documents are focused on the mechanics: Building the project objectives and the list of deployable features and functions you want to achieve. Less is written around the topics of how to build a manageable project, control the associated scope, and, most importantly, gain internal consensus. Falling short on the organizational coordination can imperil projects every bit as much as having faulty project plans.
It’s a well know fact that over half of all technology projects fail. This has unfortunately been going on for years. So it makes sense to spend some time thinking about how to gain an edge as you are planning.
It is not always bad to have failure in projects. You have probably heard of the ‘fail fast’ mantra that is part of an agile approach. Unfortunately, too often organizations are not well organized to embrace failure, and you may get tainted by being part of a failed project—culturally that is not a great approach when delivering on digital transformation.
One of the more important things you can do is build in experimentation as a part of your mission (see my prior post on mission), and the project scopes that result from that mission. Few things in transformation are more painful than finding out in the middle of a project you are on the wrong track—and have no room in the schedule to address the problem.
Hone-in on the details: Vision requires scope
Scope has relevance to the overall mission. You can determine the scope by mapping the vision or mission statement to the specific project underway. Be sure to take the time to think about the strategy needed to accomplish the identified goals. If the goals are clear, they will map directly to the strategy. It is always wise to attribute the mission to the CEO or the board to reflect buy-in from the top to the bottom of the organization.
When thinking about the scope of the mission, a necessary discussion is organizational readiness for the changes that transformation will drive. Not long ago I visited a Fortune 500 company where the mission seemed to be in good shape, until I asked about organizational alignment to the mission. A substantial disconnect soon became clear, and as a result risk to the project was tremendous. If the organization is not prepared for a full-on deployment of technology that will span multiple business areas and drive changes in substantial parts of the organization, a less aggressive approach with a more ‘stepped’ deployment might be warranted.
Big bang or incremental roll out?
If you are doing a full transformation of both technology and organization, a big bang approach requires the most care and planning. On the other hand, incremental roll outs tend to be more expensive and take more resources over a typically longer time. Tradeoffs here are substantial, and there is no single right answer for the approach you should take.
If your organization is taking it’s first step in transformation, you might want to look for a quicker win—which means that an incremental approach is preferred. That means you need to build longer project time lines and make sure company leadership is well informed of the reasons for the incremental approach.
Big bang deployment typically requires much more internal communication and testing because in most cases there is no turning back. Many companies include the communications plan as a part of the broader project to ensure that all constituents are well informed and are part of the effort.
An extension of that communications plan is the enablement of the impacted areas of the business. Too often this is an area that gets short changed. One way to move a successful deployment to something much less is to fail to plan for enablement of your constituents. Since a big bang implies that everything is changing, it is a huge risk to under plan for the education and enablement of the people that will be using the system.
Chris Martin, CIO of Pep Boys has taken a focused approach to the testing and enablement of their transformation, “We cut off all development 6 months before the launch. That gives us time to test, train, and test some more.” It may seem conservative to build in this much time, but many companies are surprised at what the internal transformation effort dictates.
Mapping the technological impact against the organization is an important step of the pre-deployment phase. If approaching a complete front office replacement, including things like e-commerce, customer interaction, content management, promotions, and customer life cycle management, you are cutting across most of the company functions. This dictates a fair amount of preparation—both technical and business—to assure the organization can handle the impact. Even if you have technically integrated solutions, don’t underestimate the challenge you will face regarding business impact.
Technology is an enabler in transformation, and a key part of the scope equation, but it’s never a good idea to start with technology—the organization first needs to embrace the need for change far before starting the deployment of a specific technology. Defining that needed change will help determine the right tools and technologies for your organization. In most cases you can get a long way down the road toward identifying the size, scope and impact of the transformation you are targeting before you select the solution that will enable it.
Minimum viable product
In reviewing your scope, a valuable exercise is to review the entire set of requirements and break them into categories like ‘critical’, ‘must have’, ‘differentiator’, and ‘like to have’. The idea is to fully understand what each requirement contributes to the overall effort and the value it brings. Whatever criteria you use, defining what the ‘minimum viable product’ is can help you establish an early baseline in case you have to make adjustments down the road.
For many companies, defining the MVP first and then delivering incremental improvements on short timelines is the best approach to accomplishing the benefits of MVP. Steve Wentzell, Sr. Director Ecommerce at Lids described how they approach this: “A couple of the keys for Lids in our deployment and controlling the scope was to have our technology vendor heavily engaged in the first deployments while we were learning the technology, and then making sure that we had a very concise rollout plan with releases that everyone in our business understood and agreed with…”
The net around managing scope in digital transformation projects is to realize that while there is a major IT and PM aspect to projects, scope typically touches much more broadly across the organization. Managing the project scope communications—from the executive level to every impacted part of the business will pay massive benefits.
