Project Insurance

Our newsletter theme this month is all around Insurance. In talking with our customers, one question we receive frequently about our Agile methodology approach is: “How can you provide us insurance that the final product will deliver business value if you allow so much to change along the way?”. It’s a valid question, and a primary reason that organizations fear moving away from the waterfall methodology.

They have a conjecture that, because they define all the requirements up front, the final product will fully deliver all the value they wish. When, in reality, the value they need changes along the way. As the business environment changes, the team learns new things, technology changes, and outside factors like the current pandemic present new challenges not thought of during the planning phase of the project.

Our approach still begins with objectives, requirements, design, architecture and an overall release roadmap. We draft objectives to ensure we understand what success of the project looks like and how we will measure to determine if we are hitting the mark. We prioritize our release plan and backlog with the highest value deliverables first, to ensure each feature positively impacts one or more of the objectives.

The difference in our approach comes from knowing that our line of sight for work in the next 3 to 5 sprints is clear and focused but beyond that things can change, impacting the priority of feature development. Introducing new features or changes to existing feature's priority is, and always will be, a part of software development projects. Rather than having a burdensome change request process or flat out refusing any “scope creep” we propose a simple review and impact analysis of each request.

Every decision about changing the release plan or adding new work should be scrutinized by the team and project sponsor. Not because change is bad, but rather to determine if the change reflects the real priority, achieves business value quicker, and directly impacts one of the objectives for the project. If the answer is no to any of those items, the change can be noted but should be moved to the bottom of the backlog for review at a later time.

If the change is deemed worthy of inclusion, an impact analysis must be completed and reviewed with the team and project sponsors to show what will happen to the current release plan as a result. Does the date move? Does something else get dropped from the plan? Regardless, that transparency must exist so that everyone involved can understand the impact of the request.

Our Value Focused Delivery approach to managing projects provides this level of transparency and prioritizes progress over activity. We know how to manage large scale projects using Agile methodologies to confidently answer the above question for our customers. Contact us today to learn more about this approach and how Clientek can help you achieve more business value in a shorter timeframe on your project.