Delivering Cloud Transformation Excellence: Assumptions, Dependencies, Pricing Models, Backlogs, & Capacity - Part 5

By: Ron L'Esteve   |   Updated: 2022-08-25   |   Comments   |   Related: 1 | 2 | 3 | 4 | 5 | 6 | > Cloud Strategy

Problem

Clearly defined project assumptions, dependencies, pricing models, product backlogs, and capacity are all critical factors for the success of a Cloud Transformation project. Since approximately 70% of cloud transformation projects fail, customers, vendors, project teams, and leadership personas are all interested in understanding how best to position cloud transformation projects for success during the project planning and scoping phase. They are interested in obtaining tips on how best to plan their project's assumptions, dependencies, pricing models, product backlogs, and resource capacity to deliver excellence.

Solution

While initiating a project and defining the scope of work, a list of assumptions and dependencies will need to be clearly outlined and communicated to the project stakeholders and leadership teams. Like scope and risk management processes, a change management process capturing objectives, impact analyses, governance, and communication will need to be instantiated should there be deviations from the stated assumptions and dependencies.

Typically, from a vendor's point of view, they need to work closely with a client to identify the pricing models for the project. Projects can most often range from Time and Material (T&M) to Fixed Price (FP). Since Agile Scrum projects have loosely defined initial requirements, T&M pricing models offer the flexibility to define the granular details of the scope of the work incrementally through the course of the project. This approach supports vendors in mitigating the risk associated with FP pricing models.

Estimating a project's product backlogs along with forecasting team members availability and capacity is key to ensuring that the anticipated scope of work is clearly translated into units of work that are grouped by Epics, Features, and User Stories. These granular tasks can then be assigned to members of the project team that would need to have the available capacity to deliver the work to meet project timelines. This section will detail some of the success criteria for well-defined project backlogs which effectively map to resource availability and capacity.

This article will detail tips and recommendations of planning for cloud transformation projects which are related to assumptions, dependencies, pricing models, product backlogs, and resource capacity.

Assumptions and Dependencies

The following list contains sample assumptions and dependencies that could be included as part of a transformational Cloud Data project. For example, 'customer participation' is both an assumption and a dependency for the success of the project. A custom transformation implementation project which lacks clarity with respect to requirements needs more customer participation at every step of the way. Active customer participation promotes collaboration, feedback, and clear visibility into work-in-progress (WIP) project deliverables which will help gauge earned value to date along with time and items left to complete. Once the project has been initiated, the vendor and customer have similar vested interests, objectives, and desires for successful planned outcomes which deliver business value.

• A dedicated Business Analyst will be provided outside the scope of this agreement by the client team. Business Analysis responsibilities for definition and documentation of requirements, user stories, and related activities are required for successful delivery and will be provided outside the scope of this engagement and will be provided by the client.
• The Customer will provide sufficient access to the environment, including all required network, security, and other access rights to all required areas of the environment prior to project commencement to allow remote access for delivery of the service. Failure to provide sufficient and timely access may impact the project timeline and budget.
• A Customer representative, ideally a Product and/or Owner, will actively participate in the project by attending required Scrum Ceremonies, consistently providing feedback and contributions to the work-in-progress (WIP) items and product backlog while acting as the Voice of the Business.
• Any extensive manual and automated QA efforts will require a dedicated QA resource that has not been scoped for the project.
• Source data will include structured data only that is sourced from a combination of SQL Server and Oracle.

Pricing Model

In today's competitive landscape, vendors are getting creative with their pricing models to keep customers interested in a fixed price while also reducing delivery risk. This can be achieved with a Capacity based fixed price where a customer would commit to a capacity with high-level deliverables along with variable scope that adapts based on evolving requirements. A variation of this could also be Sprint based fixed price wherein after Sprint 0 ("The Envisioning Phase"), the product backlog will be more clearly defined in Sprint 1 onwards ("The Implementation Phase"). With this approach, a contract per sprint would not be required and could fit within a larger contract. Another option would be to deliver a T&M pricing model contract for Phase 1 (Sprint 0) with the goal of defining the high-level requirements clearly and translating that into a detailed product backlog. Thereafter, the remaining deliverables could flow into an FP contract that executes the agreed upon Sprint 0 requirements.

These pricing models support the Agile way with the goal of collaborating closely with the customer during the pre-implementation phase to better understand their requirements, expectations, and roadmaps to tailor the best pricing model. This will increase both customer and vendor satisfaction while minimizing risk for both parties. Walking through proposals with customers is a great way to ensure alignment on the planned course of action and will minimize any potential risk to the project through effective control mechanisms. In addition to the pricing models for the envisioning and implementation deliverables, it is also important to capture other Terms, Conditions, and Service Level Agreements (SLA) that may impact pricing. These may include time to resolve, non-disclosure agreements (NDA), licensing and security requirements, contractual validities, travel costs, on-shore vs. offshore resource pricing model splits, resource on-boarding and off-boarding requirements and associated fees, and more.

Product Backlog and Resource Capacity

A product backlog typically consists of anticipated deliverables that have been defined during prior phases. It may capture both functional and non-functional requirements and can be added to or evolved through the course of the project. The key to successful management of a product backlog is to prioritize the critical deliverables per sprint. The duration of a sprint can be defined as part of the Planning and Initiation phase, although this standard has typically been '2 weeks' in duration for transformational cloud projects. In the spirit of Agile, the product backlog will be evaluated and re-prioritized at various iterative intervals as new business requirements present themselves to align with business priorities. A self-regulated and multi-skilled team may be able to solve challenges at a faster rate while working through the product backlog and prioritizing scope at a more accelerated rate.

While estimating the size and effort of the product backlog defined deliverables, buffers and stabilization periods help to account for uncertainty when needed. Also, the productive time of team members should be considered. Up to 30% of sprint capacity is usually spent on re-work related to defect fixes or enhanced requirements, security, and tech reviews. For example, in an eight-hour day, a Data Engineer may only have 5 productive hours to build an ELT Pipeline. The rest of the time might be split between research, requirements gathering, and other development related tasks and meetings. Whenever possible, reusable artifacts and frameworks from previous projects or a CoE repository would help with reducing time and effort on tasks.

The skill level of the team member that is executing the deliverable will also contribute to the time and effort related to the task. For example, a lead data engineer that has 5+ years of experience with ELT pipelines on a particular cloud technology platform will take lower time and effort on the deliverable than on who is more junior and inexperienced. Correlation and regression models based on data from previous projects help with forecasting numerous scenarios, While the estimation of time and effort can be somewhat quantified more accurately through forecasting ML algorithms, a general best practice would be to take into consideration a variety of factors for estimating the time and effort required to deliver tasks defined within the product backlog.

Scrum ceremonies including Daily Standups, Sprint Planning, and Retrospective meetings significantly help with gaining a clear understanding of the rate of progress that has been made to date, what is remaining, and mitigation plans for any impediments that the team members are facing. They also help with gaining clarity around the size of the assigned tasks and utilization availability of the resources. For scope and requirements that change often, a formal change management process that includes Change Requests (CR) would be the ideal way of socializing the awareness of the required changes and to manage the product and financial contractual impacts effectively. This will support both the buy-in and implementation of the change and will maintain positive relationships between clients and vendors. Minor scope changes with little to no increase in scope and re-work to the product backlog can be managed at the discretion of the Scrum Master.

In addition to capacity and utilization planning, vacation plans, skill ramp-up training opportunities, motivational recognition and rewards programs, and resource rotation plans resulting from lack of skills or attrition all need to be accounted for to effectively manage resources. For example, an experienced consultant would be more expensive and impact margins while a junior consultant would not be experienced enough and may jeopardize the project without appropriate training. A mixed model is key where an experienced lead with 50% or less utilization, coupled with mid to junior level team members with 50% or more utilization will result in a greater probability of success.

Next Steps

• In part 6 of this series on Delivering Cloud Transformation Excellence, we will continue the discussion around Project Management Excellence by focusing efforts on tips related to project and team communication, collaboration, and governance.
• Read more about Time-and-Materials vs Fixed Price: Which to Choose for Your Project? | by Yevheniia Korotia | Medium
• Read more about Team Backlog - Scaled Agile Framework
• Read the 8 Best Practices of Capacity Planning | Planview
• Learn more about RAID Analysis Template - Risks, Assumptions, Issues and Dependencies - GroupMap

About the author

Ron L'Esteve is a trusted information technology thought leader and professional Author residing in Illinois. He brings over 20 years of IT experience and is well-known for his impactful books and article publications on Data & AI Architecture, Engineering, and Cloud Leadership. Ron completed his Master’s in Business Administration and Finance from Loyola University in Chicago. Ron brings deep tec

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips