Scope Definition & Schedule Basics – A Significant Risk in Transformations

Introduction

In my experience, the inadequacy of proper program and project planning, scheduling, and schedule maintenance is one of the most prevalent reasons many transformation programs fail.

When called upon to assess or turn around failing transformations, I often encounter a complex team challenge. In these situations, the client and their system integrators (SIs) grapple with many conflicting reasons for delivery delays and budget overruns. Yet most of these conflicting reasons are symptomatic of a more basic management gap.

The transformation scope typically leverages standard enterprise commercial-off-the-shelf configurable enterprise software (COTS) to automate and integrate a defined set of business processes and analytics, along with additional reports, integrations, conversions, enhancements, workflows, and forms (RICEWF).

Yet, the transformation organization's definition, structure, and delineation of the solution scope are often inconsistent and ambiguous. This inconsistency and ambiguity in solution scope result in inadequate work product definitions and an even poorer reflection of those work products in the delivery plan and schedule.

The result is often multiple project, product, and scrum masters spending much time chasing team members for their respective work product status regarding the plan. Often, the statuses are subjective and inconsistent across teams, resulting in inaccurate forecasting of delivery dates and budget adherence.

The most consistent flaw in failing transformation programs and projects is the lack of traceability and clarity between the work product scope and the schedule. This flaw can be easily remedied if all engaged parties not only understand but also internalize the criticality of a well-defined work scope and an integrated schedule. It's crucial to emphasize that these factors are not just important, but they are the very key to the success of any transformation program.

Solution Scope Definition - The Basics

Over the past 30-plus years, enterprise COTS solutions have existed and been implemented across multiple industries for multiple functions. Many of these COTS solutions provide the end client with the business processes and analytics they automate, integrate, and provide a client organization. All the end client and their SIs need to do is groom the respective process and analytical scope for what will be relevant for the initial transformation and rationalize the minimal viable products (MVP) required per the process and analytical scope.

In my experience, I prefer to rationalize these processes and analytical MVP work products along the following criteria:

• Requirements rationalization criteria along with a requirements traceability matrix (RTM).
• What is required to support the solution in a production environment?
• What is required to test and fully validate the solution and all integration points?
• What is required to train and support the end users using the solution?

These MVP work products are consistent across all in-scope processes and analytical reports (or visualization). The only exceptions should be managed through a change control process.

Now that we have a basic understanding of the solution scope by process and the MVP work products, we can address how that should be reflected in a delivery schedule.

Schedule Engineering Basics

The resulting MVP work products are expected for every process in the transformation's scope. The key question is how to best represent these MVP work products in the plan for scheduling purposes.

In my experience, those MVP work products are best represented as tasks per process in the transformation solution's scope. However, those tasks do not all start or finish simultaneously over a long period. This is one of the most common scheduling mistakes that can create chaos and make it challenging to manage expectations in the earliest stages of a transformation.

Not all processes and respective work products will start at the same time. Requirements must be rationalized before rationalizing any process-specific gaps for RICEFW purposes. Process requirements, gaps, and configuration specifications must be approved before any configuration work is conducted. This is why most scheduling tools provide the “Precedence Diagramming Method” (PDM, also known as Activity on Node or AON) scheduling method, which includes four different types of task dependencies which are the following:

• Finish-to-Start (FS): In an FS relationship, a successor task cannot start until its predecessor task has finished.
• Start-to-Start (SS): In an SS relationship, a successor task can only begin once its predecessor task has started.
• Finish to Finish (FF): In an FF relationship, a successor task cannot finish until its predecessor task has finished.
• Start-to-Finish (SF): In an SF relationship, once the predecessor task can start, the successor task can finish

Regardless of the number of processes in scope and the respective MVP work products that must be completed, there is a natural sequence from one MVP work product to the next.

Constructing and defining the relationships between these MVP work products provides the delivery manager with a template they can copy and replicate by team, wave, or increment and process therein. The only variations on these MVP work products will be based on the process complexity, number of RICEFW objects, and respective basis of estimate (BoE) for resources and duration.

Unfortunately, many transformations that fail in their delivery goals lack consistent plans and schedules within and across the teams, waves, or increments. These plans often resemble ‘punch lists’ that a respective team considered at a particular point in time.

Basic Schedule Mechanics

All scheduling tools operate from simple rules and algorithms, making planning and managing a delivery schedule easy once the scope is fully planned and delineated by wave/increment and team.

First, does the delivery plan start with a planned start date, or is there a targeted completion date? Having both dates can allow a team to take advantage of any float or slack in the plan. Float or slack in the plan is the number of days a task can be delayed before impacting the project's overall timeline. If the team has both dates, they can properly plan and baseline the delivery schedule, incorporating the float or slack to the delivery team’s and PMO's advantage.

Secondly, all scheduled work product tasks have at least one or more progress-related fields available. Those fields, at a minimum, include the following:

• Percent Complete: The estimated amount of work product completed in percentage terms.
• Remaining Duration: This field is calculated from the forecasted total duration times the remaining percentage to complete the work product. This remaining duration can often be manually adjusted, which will impact the percent complete.
• Actual Start and Finish Dates: These are the actual start and finish dates for the work product construction. These dates ‘anchor’ the work product tasks in the plan and should be properly maintained.

Finally, all scheduling tools require a status date from which status will be assessed. A status date is the date from which all MVP work products, either in progress (but not completed yet) or not started yet, will be scheduled to the right of that status date. Setting the status date and updating the schedule based on that date provides near-time forecasting of where the product/program and project manager must focus their attention.

As with the mistakes made with basic schedule engineering, the basic schedule mechanics are often overlooked.

I have personally found numerous transformation delivery schedules and teams communicating an “On Schedule” delivery when, all the while, the plan was never updated with a status date, there is no baseline reference, and there is no verification on the actual dates. Once the status date was set and an update on the plan was executed, the average delivery forecasted a quarterly delay at a minimum.

Conclusion

An enterprise transformation requires significant time, people, and funding. Many of these basic transformation schedule management mistakes and issues can be avoided. It does not matter if one utilizes a traditional waterfall, agile, or hybrid methodology. Methods and tools to avoid these costly mistakes and issues include the following:

• Standardize, automate, and maintain planning methodologies and templates for ease of use and efficiency.
• Integrate the resulting plans from templates with execution solutions such as JIRA, Planner, Azure DevOps, etc.
• Standardize and automate work product measurements within the respective execution solution.
• Conduct delivery planning reviews and verify the sequencing of work product by respective scope.
• Conduct ‘in-flight’ audits of delivery plans to published status reports
• Ensure that the PPM tools are maximized to their full potential in capability and integrations.
• Ensure delivery management teams are experienced, skilled, and educated in the planning and managing the delivery methodology and available tools.
• Continuously ask for feedback and suggestions on improving delivery planning and management.

Even the best agile scrum teams I have worked with understand the criticality of work product dependencies. I recently worked with a great team that had to maintain work product dependencies in a spreadsheet since the global client preferred to use #JIRA only (which does not have a scheduling engine). Good schedule planning and management are critical to a transformation delivery success. Ensure your SI partners is in alignment with this criticality.