Search

The Business Case – A Key Artifact of A Project Managed As Per PRINCE2

One of the key deliverables in the process of initiating a project managed using the PRINCE2 methodology is to create the business case document. A project in PRINCE2 is defined as ‘A management environment that is created for the purpose of delivering one or more business products according to a specified business case’. What is a business case document? Why is it important to create one? What are the key decisions made using the business case document when initiating a project? How will the business case help in managing and controlling a project and in ensuring that the project continues to deliver business value? This article aims to address above questions.   Why create a Business Case document? A business case is mainly used to document the justification for undertaking the project, based on the estimated cost of development and implementation against the risks and anticipated business benefits and savings to be gained. It is a justification for an investment based on the costs versus the anticipated business benefits of the solution option selected for implementation.  The business case is a primary mechanism of project decision-making and is a means of assessing alternative and competing investment / solution options.  When should you create the Business Case document? For organizations following PRINCE2, to get to the point of creating a business case document itself involves a big process. Requirement for projects arise from different sources. For example strategic level stakeholders may have strategic objectives that they wish to fulfill which may result in projects. Similarly tactical managers, functional managers and even operational staff may have problems that need to be resolved or business opportunities that they want to take advantage of which may result in projects. The context or the environment that they operate in and the stakeholders involved too may have an impact in creating requirements for new projects. A project mandate would first of all be generated once a business need such as above is identified. The scope inclusions and exclusions of the project should be identified and will help identify solution options to meet such requirements. The initial group of individuals would then be generating solution options to solve the identified problems or opportunities. For each solution option a detailed feasibility study should be done along the four main feasibility study dimensions of operational feasibility, technical feasibility, time feasibility and cost-benefit feasibility. This would help the team identify the advantages and disadvantages of each solution option and help select the most suitable solution option. This analysis must also include an initial assessment of the cost, potential timelines and the risks involved. Creating the Business Case and sections of the document The business case documents the justification for undertaking the project, based on the estimated cost of development and implementation against the risks and anticipated business benefits and savings to be gained. The content for the document is based on the analysis explained above. The sections of a properly formulated business case are as listed below. Executive Summary – Summary of the content of the business case document including details about the organization, business problem  / opportunity, key stakeholders, solution options evaluated and the solution option selected. Reasons for the project – Reasons as to why the project is needed including analysis of the current state, the future state and an identification of the gap. Solution options – The different solution options evaluated outlining the rejected solution options and detailing out the preferred solution option. Feasibility analysis – A summary of the feasibility analysis done on the identified solution options. Expected benefits for the selected solution option with explanations and assumptions. Expected disbenefits for the selected solution option with explanations. Summary of project costs taken from the project plan. If the project plan is not created yet it would be good to have an outline cost for the selected solution option. Investment appraisal – The organization may do an ROI, NPV, IRR analysis to ascertain the potential viability and benefits from the project. Risk analysis listing out a risk log with positive and negative risks along with risk mitigation strategies. Timescales – Outline execution plan that will be detailed out in the Project Initiation Document (PID). Continual assessment of project progress using the Business Case The business case document provides a blueprint based on which project progress can be monitored by the project manager and the project board. It provides a means for continuing to assess the viability of the project. In PRINCE2, the Project Board normally reviews the business case at the project initiation stage, end of each project stage, when any exceptions arise and at stage or project closure. The business case would be the main input to create the Project Initiation Document (PID) for the selected solution option. Some teams put a summary of the business case findings as a section in the PID document itself and use it to make an elevator pitch to the business sponsor and other senior executives of the project board. Once the project is approved, the project manager is assigned and he would create the project charter document with key inputs from the business case. The Project Manager and the Project Board will monitor the ongoing viability of the project against the business case. At the end of each stage or iteration the relevant stakeholders will sit together, evaluate the deliverables related to both the product and the process against the expected benefits identified in the business case to ascertain whether the business value set out to achieve is being met. Decisions to get the project back on track would thus be based on the baseline intentions defined in the business case. Finally, the business case is used to assess whether benefits are achieved when the project is delivered through a post implementation review.  The business case is not a constant. It may change multiple times during the lifetime of the project. Evaluation at the end of each iteration or stage will help the project team and the project board realizes that changes are required in terms of objectives, expected business value, scope or even timelines. Hence, the initial business case may become invalid and thus be required to be updated with the consensus of the key stakeholders.  The discussion above is just an introduction to the ocean of creating business case documents. Hope this will inspire you to further dive into this ocean.
Rated 4.0/5 based on 20 customer reviews

The Business Case – A Key Artifact of A Project Managed As Per PRINCE2

362
The Business Case – A Key Artifact of A Project Managed As Per PRINCE2

One of the key deliverables in the process of initiating a project managed using the PRINCE2 methodology is to create the business case document. A project in PRINCE2 is defined as ‘A management environment that is created for the purpose of delivering one or more business products according to a specified business case’.

What is a business case document? Why is it important to create one? What are the key decisions made using the business case document when initiating a project? How will the business case help in managing and controlling a project and in ensuring that the project continues to deliver business value? This article aims to address above questions.


 

Why create a Business Case document?

A business case is mainly used to document the justification for undertaking the project, based on the estimated cost of development and implementation against the risks and anticipated business benefits and savings to be gained. It is a justification for an investment based on the costs versus the anticipated business benefits of the solution option selected for implementation.  The business case is a primary mechanism of project decision-making and is a means of assessing alternative and competing investment / solution options. 



When should you create the Business Case document?

For organizations following PRINCE2, to get to the point of creating a business case document itself involves a big process. Requirement for projects arise from different sources. For example strategic level stakeholders may have strategic objectives that they wish to fulfill which may result in projects. Similarly tactical managers, functional managers and even operational staff may have problems that need to be resolved or business opportunities that they want to take advantage of which may result in projects. The context or the environment that they operate in and the stakeholders involved too may have an impact in creating requirements for new projects. A project mandate would first of all be generated once a business need such as above is identified.

The scope inclusions and exclusions of the project should be identified and will help identify solution options to meet such requirements. The initial group of individuals would then be generating solution options to solve the identified problems or opportunities. For each solution option a detailed feasibility study should be done along the four main feasibility study dimensions of operational feasibility, technical feasibility, time feasibility and cost-benefit feasibility. This would help the team identify the advantages and disadvantages of each solution option and help select the most suitable solution option. This analysis must also include an initial assessment of the cost, potential timelines and the risks involved.



Creating the Business Case and sections of the document

The business case documents the justification for undertaking the project, based on the estimated cost of development and implementation against the risks and anticipated business benefits and savings to be gained. The content for the document is based on the analysis explained above.

  • The sections of a properly formulated business case are as listed below.
  • Executive Summary – Summary of the content of the business case document including details about the organization, business problem  / opportunity, key stakeholders, solution options evaluated and the solution option selected.
  • Reasons for the project – Reasons as to why the project is needed including analysis of the current state, the future state and an identification of the gap.
  • Solution options – The different solution options evaluated outlining the rejected solution options and detailing out the preferred solution option.
  • Feasibility analysis – A summary of the feasibility analysis done on the identified solution options.
  • Expected benefits for the selected solution option with explanations and assumptions.
  • Expected disbenefits for the selected solution option with explanations.
  • Summary of project costs taken from the project plan. If the project plan is not created yet it would be good to have an outline cost for the selected solution option.
  • Investment appraisal – The organization may do an ROI, NPV, IRR analysis to ascertain the potential viability and benefits from the project.
  • Risk analysis listing out a risk log with positive and negative risks along with risk mitigation strategies.
  • Timescales – Outline execution plan that will be detailed out in the Project Initiation Document (PID).

Continual assessment of project progress using the Business Case

The business case document provides a blueprint based on which project progress can be monitored by the project manager and the project board. It provides a means for continuing to assess the viability of the project. In PRINCE2, the Project Board normally reviews the business case at the project initiation stage, end of each project stage, when any exceptions arise and at stage or project closure.

The business case would be the main input to create the Project Initiation Document (PID) for the selected solution option. Some teams put a summary of the business case findings as a section in the PID document itself and use it to make an elevator pitch to the business sponsor and other senior executives of the project board. Once the project is approved, the project manager is assigned and he would create the project charter document with key inputs from the business case.

The Project Manager and the Project Board will monitor the ongoing viability of the project against the business case. At the end of each stage or iteration the relevant stakeholders will sit together, evaluate the deliverables related to both the product and the process against the expected benefits identified in the business case to ascertain whether the business value set out to achieve is being met. Decisions to get the project back on track would thus be based on the baseline intentions defined in the business case. Finally, the business case is used to assess whether benefits are achieved when the project is delivered through a post implementation review. 

The business case is not a constant. It may change multiple times during the lifetime of the project. Evaluation at the end of each iteration or stage will help the project team and the project board realizes that changes are required in terms of objectives, expected business value, scope or even timelines. Hence, the initial business case may become invalid and thus be required to be updated with the consensus of the key stakeholders. 

The discussion above is just an introduction to the ocean of creating business case documents. Hope this will inspire you to further dive into this ocean.

Rumesh

Rumesh Wijetunge

Chief Innovation Officer - Zaizi Limited, Chief Operating Officer - LearntIn (Pvt) Ltd., Director /

Rumesh is an IT business leader with over 12 years of industry experience as a business analyst and project manager. He is currently the CIO of Zaizi Limited, a UK based data management company heading the operations in Sri Lanka, the COO of LearntIn, a global training institute based in Sri Lanka and is also a lecturer / trainer at multiple private universities on management, IT, business analysis and project management subjects. He is the current president of the IIBA Sri Lanka chapter and is one of the most qualified and sought after trainers in Sri Lanka. Refer his LinkedIn profile for more details and to see more articles he has written on linkedin

Leave a Reply

Your email address will not be published. Required fields are marked *

Suggested Blogs

Brainstorming – Promoting Creative Thinking Among Teams : Project Management

BABOK™ version 3 defines brainstorming as a technique intended to produce a broad or diverse set of options. The PMI-PBA® guide defines “Brainstorming” as a data gathering technique that can be used to identify a list of ideas from a diverse group of individuals in a short period of time.  Brainstorming is a great method to promote creative thinking about a business need. During brainstorming a group of people meet to generate ideas around a specific area of interest or a topic or problem with the participants encouraged thinking freely and moving into new areas of thought. Thus, these areas of interest can be related to problems, opportunities, solution options, stakeholders, risks, features etc. Brainstorming is best applied in a group since a key objective of using this technique is to draw upon the experience and creativity of individuals participating in the brainstorming session. There are instances where a brainstorming session is run by a single individual when there is no group setting. The individual may let his or her mind run wild but in a controlled manner in order to generate as many ideas as possible. Steps of a brainstorming session The BABOK® describes three main aspects to run a successful brainstorming session. 1) Preparation Normally a facilitator who has some sort of interest in the topic leads a group brainstorming sessions. The facilitator will first of all plan for the session by identifying the participants, their roles, the area of interest to be taken up for discussion, methodology for idea generation, evaluation and documentation along with time and other resources required for the session. 2) Session The facilitator will then get ready for the brainstorming session by setting up the meeting, inviting participants, defining the agenda and by organizing the required logistics on the day of the session. The facilitator must set the ground rules for the session and encourage everyone to participate in creating ideas. The ideas generated must be recorded in some form (white boards, sticky notes, on paper etc.), group similar ideas together by using affinity technique and select most suitable or preferred ideas using voting methods (dot voting, weighted criteria). The selected idea(s) may be built upon further where the team may brainstorm even further amidst the guidance of the facilitator. 3) Wrap-up During the wrap-up of the brainstorming session, the facilitator may count the votes, finalize the detailed ideas elicited during the session, document them in a format that can be shared among participants and other stakeholders and then finally share the results among stakeholders. Ideas may also be generated for further evaluation and discussion during future brainstorming sessions. Brainstorming session types There are different types of Brainstorming as defined in the PMI-PBA® guide. 1) Free-Form A free-form brainstorming session gives freedom to the participants to contribute to the discussion of their own accord. The facilitator poses the idea or the problem to be discussed where anyone participating in the discussion is given the freedom to contribute at any point in time. A free-form brainstorming session may get chaotic when discussing highly sensitive topics or when it is presided by dominant participants. Similarly, the more conservative participants may be silent and not be willing to contribute thus resulting some key ideas been left out. 2) Round Robin Round Robin brainstorming sessions help overcome issues in free-form brainstorming sessions where each participant in the discussion is allowed to voice his or her opinion. Each participant is given a chance to contribute one by one.  If the participant has no ideas,  he or she may just ‘pass’ on the baton to the next participant in the discussion. This method is suitable when the room is full of experts from whom you as the facilitator want to get as much information as possible. 3) Silent Writing / Pencil & Paper Sometimes, introverts prefer to communicate ideas by writing them down rather than voicing them in public. Highly sensitive ideas can also be communicated using this manner. This method allows people to express ideas while maintaining their anonymity. 4) Mind Mapping Mind mapping is a more visual method of brainstorming where the team tries to show the ideas generated in a diagrammatic format.  Mind mapping helps visually represent ideas on a canvas and helps break down complex ideas along with the interrelationships among those ideas. 5 )Nominal Group Technique A nominal group technique is normally conducted in order to generate a few key ideas from a group of Subject Matter Experts. This technique involves a formal process presided by a facilitator who first of all spells out the objectives of the session. The participants build upon the idea and generate more detailed ideas. These ideas are grouped into themes and listed down on a white board. Each participant is able to clarify doubts on any of the ideas listed down. The facilitator then conducts a round of voting, where each participant is asked to vote for ideas in the order of preference. The ideas receiving the highest number of votes are prioritized and decomposed further in order to create a concrete list of ideas. Conclusion Brainstorming is a highly collaborative and useful technique to create team synergy and a conducive environment to generate highly innovative ideas within a very short period of time. If used wisely, it can be a great asset for any organization.  
Rated 4.0/5 based on 20 customer reviews
Brainstorming – Promoting Creative Thinking Amon...

BABOK™ version 3 defines brainstorming as a tech... Read More

Project Management Methodologies: Evolution and Benefits

Over several decades, projects have been initiated or undertaken due to market demands, business needs, at the behest of customer request, technological advancements and to comply with regulatory requirements. As enterprises approach some degree of maturity on managing projects, it becomes necessary for streamlining and standardizing the way these projects are executed, be it product development or providing services.Multiple project management methodologies were followed and in fact, newer methodologies have evolved lately and have been adopted by organizations depending on the degree of cultural challenges and resistance exhibited by the people. We will look at some of the key project management methodologies followed in today’s world.WaterfallThe first formal description of the Waterfall model is often cited as early as 1970 in an article by Winston W. Royce, although he did not use the term Waterfall in that article. It was the first process model to be introduced and is simple and easy to understand. Waterfall method has seen an abundant usage in projects where the needs or requirements are well understood and do not change much over time. It follows a linear development by phases with clearly defined stage gates and review processes. Each of the phases is cascaded down and will start when the defined goals are met by the previous phase and signed off.The phases are-Requirement Analysis: - User requirements are gathered through workshops, elicitations and business rules, schemas are definedSystem Design: - Blueprint of the system is charted.Implementation: - Developing the actual product or software happensSystem Testing: - Proving that the software works through unit/integration testing and fixing defects that come out of it.System Implementation: - Productionizing the softwareMaintenance: - Operation, maintenance of the production software.The main advantage of this model is, it allows for segmenting the work like departments and manage them easily. This model also faced some major criticisms which even led Royce to change his view towards Waterfall. It is less costly to change requirements during the design stage and it is more expensive to adapt to changes when construction has already started. This method does not also provide a working version software to client till production and there is no provision to improvise design of the system midway as there is no feedback mechanism.The Waterfall  methods can be adopted on a fixed scope and fixed pricing contracts where the clients don’t expect the requirements to change frequently over time. It would also be beneficial if the project team is also experienced in this type of plan-driven heavy-weight approach to deliver quality products. The performance of the project is measured based on the delivery date and the budget utilized.AgileIn 2001, a lot of practitioners using Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal and Feature-Driven Development convened in Utah ski resort and were sympathetic to the need for an alternative to documentation-driven, heavyweight software development processes. As a result, “Agile Manifesto” was signed paving way for Agile Software Development. It is an umbrella term for several iterative and incremental development and some of the popular include Scrum, XP, Crystal, DSDM, FDD, and Lean."Walking on water and developing software from a specification are easy if both are frozen."- Edward V. BerardThe fundamental difference between Waterfall and Agile is that Waterfall  delivers product increment at the end of the project but Agile emphasis on delivering smaller increments more frequently through multiple iterations. Agile harnesses customer’s competitive advantage and proposes process that accounts changes even late in the game. This is achieved through adaptive planning and evolutionary design. The client is also involved throughout the development process unlike Waterfall  method and feedback is received in every iteration through a feedback loop and the product is improvised based on the feedback. But can all projects be executed in Agile? The answer is no, as each project is unique and if the scope of the projects is clear like still water and does not change over time, executing those projects in Agile would be an overkill.The most common Agile methodologies that are widely used and gained popularity are Scrum and Extreme Programming. Scrum focuses on shorter iterations called Sprints ranging (generally) 2 weeks to 1 month and emphasis on delivering shippable product increments every sprint. In Scrum, design is emergent and evolves over a period of time. The Scrum framework consists of Product Owner, Scrum Master and Development Team.Product Owner: - Responsible for the product vision and building the product right. A good product owner should prioritize requirements and is empowered to make decisions about the product.Scrum Master: - Serves as servant leader, helping team members work together cohesively, removing impediments to progress, facilitating meetings and discussions.Team: - Cross-functional and responsible for who will work on which tasks, which engineering practices to be followed necessarily to achieve project goals.Extreme Programming created by Kent Beck also advocates frequent releases in shorter development lifecycles. The most common elements of XP are pair programming, code review, test-first development, continuous, collective code ownership, metaphor, coding standards, refactoring, simple design, and frequent customer collaboration. The idea is based on the benefits of traditional software engineering practices when taken to extreme levels. Sometimes Scrum will also employ some of the engineering practices from XP like refactoring, simple design, TDD etc.Agile harnesses customer’s competitive advantage by welcoming requirement even late in the development. The Agile methodologies will be most suitable for time and materials contract where the time and cost are fixed but the scope changes frequently based on customer needs. The performance of the Agile projects is measured based on the value delivered to the customer.KanbanThe Kanban methodology (originated from Toyota Production System) as formulated by David J. Anderson is also incremental and evolutionary like the Agile methodology and recommends system changes for organizations to function optimally. Kanban mainly focuses on delivering continuous flow of value to the clients and it accomplishes it by placing constraints on the system.It is based on below core principles,Visualize the workflow: - Ability to see all the work items of each otherLimit WIP: - Balances the flow of work items on each lane to generate optimal outputManage the flow: - Pull the items from backlog (instead of push) when each work item is finished thereby enhancing the flow of values quickly.Make process explicit: - Clearly define process and socialize with the team.Feedback loops: - Encourages standup meetings (10-15 minutes), reviews to incorporate feedbacksImprove collaboration: - Teams achieve continuous delivery through shared knowledge and collective understanding.Kanban is more useful when the priorities changes frequently and it also balances demand against the throughput (cycle time and lead time) which guarantees the most valued features are being delivered to the client. Similar to any of the Agile methods, this method is highly responsive to changes. It also maximizes the amount of work not being done by eliminating waste and activities that don’t add value. Scrum doesn’t allow changes mid-way during the sprint, but Kanban can help in adding or removing backlog items any time during the project and helps in continuous delivery.Kanban is used widely when there is a continuous stream of work and tackling a small number of tasks fluidly and concurrently. It is also suitable for time and materials contract similar to Scrum Framework.ConclusionThere are many more project management methodologies followed in the industry and each project may demand specific methods to be successful. Now hybrid models are getting evolved like a mixture of Waterfall  and Agile that gives the flexibility to pivot and use the best methods for a specific aspect of the project. Regardless of what method has been employed to successfully complete the project, there is also going to be a need of tools as well along with process models that are flexible enough to allow to collaborate across the enterprise and deliver projects.
Rated 3.5/5 based on 2 customer reviews
Project Management Methodologies: Evolution and Be...

Over several decades, projects have been initiated... Read More

Fail Fast: A Case Study of Agile Correcting on-the-go for Project Success

Everything about Agile Methodology revolves around key values of rapid development, adaptability, and continuous improvement.  But how many times can we, as project managers, point to specific instances where our project was saved from going completely off the rails due to Agile principles?  Most of the time, small changes, and incremental values are introduced in Sprint retrospectives, to make very small course corrections, or just to reaffirm if the development manifestation is on-point with the product vision.  And as teams mature and roadmaps develop, it becomes almost mandatory to live up to stakeholders’ expectations, since individual work relationships have been established.   Every once in awhile, especially early in new projects, Agile flexes its muscles by demonstrating that adhering to the key principles can conquer ambiguous goals and handle major course corrections — preventing a major loss of time and/or wasted resources.  Sharing these experiences is important because it demonstrates the importance of Agile processes — especially daily stand-ups, the concept of delivering a viable product unit per Sprint, and Sprint demos when we are tempted to skip or skim through them. This is one such case from my personal experience as a Product Owner on a BI platform development team. Context Business Intelligence (BI) platforms are like most software products where they require the same mix of cross-functional individuals and skills to create a viable product.  In this case, the team was comprised of three software engineers, one engineering lead, one technical project/Scrum manager, and myself as the Product Owner representing multiple end-user stakeholders.  In addition, one team member filled the role as a data analyst with expertise in ETL and data warehousing, a role unique for data and BI platform development, to help translate business requirements to functional specification for the engineering team.  A user's guide to failing faster https://t.co/TH9Y4vA9EJ #agile #IT #failfast via @opensourceway by @ghaff pic.twitter.com/0Dk3N4JzXi— Agile Alliance (@AgileAlliance) May 8, 2017 Our goal was to create an analytical cube to track and analyze the performance of a transactional engine used to register and house customer account information for the procurement and payment of software products. The transactional engine was also new, being built and iterated as we started our project.   This is, of course, where the ambiguity began.  How and where would we collect the data from this system, before data existed?  What would be the defining unit of transaction?  How will the data best represent the performance?  There was no shortage of questions, but there were tight deadlines.  Analytics needed to be live no more than two weeks after the full transactional system went live, so any failures or pain points could be quickly determined and corrected before they took root as poor satisfaction for our customers. We started working on planning a roadmap and two-week sprints, with monthly production deployments and incorporating all the normal Agile/Scrum milestones in each sprint. We took what information was available to us to determine the best course of action.  Test data from the transactional engine indicated individual units to the customer agreements, not customer accounts, and supplemental information started to form a picture of appropriate data relationships, laying out the framework of our relational databases to build.   Two sprints in, we prepared for our first production deployment on schedule.  Further out, our plan put us at completion to coincide with the transactional engine go-live date.  We entered our UAT environment testing confident and satisfied.  That is, until we started to test use-case scenarios on our UAT prototype.   Action In the UAT demo, along with the Scum manager and data analyst, we quickly realized it was nearly impossible to determine the volume of customers signing up in a time period - a pretty basic measure needed to track and provide analytical value on our program performance.  The reason why?  Customers could register and be approved to transact under multiple agreement types.  Our data model didn’t define customers uniquely, but instead, used the agreement values.  The product was designed to requirements, but the requirements did not account for the translation of data to units that were valuable to business evaluation.  When we analyzed the test data, we failed to recognize this and captured the requirements correctly.   We had to redesign our data model, and do it quickly as the deadline was fast approaching.  As we were in UAT testing, sign-off was needed to release a viable product to production.  As our first action, we agreed to proceed with the ill-designed data model for the first release, though not ideal, because the first release would meet needs for now and would not be retained for the end result.  During the next daily stand-up, we suspended our normal activities to explain to the entire team what had happened.  Agile training kicked in here, with everyone showing up, ready to take on the new challenge instead of inspecting what went wrong.   Our third sprint needed to be planned, and we decided to dedicate half the team to designing the new model while the other half designed the next phase of the project.  This could work because the next phase required acquiring additional data for our model, and integration into the data model would not start until the new design was ready.  Then came our next planning meeting, which looked much more like a Joint Application Development (JAD) session.  We were all creating the new design together instead of heavier dictation by the PO and Scrum manager.   With valuable input from the engineers, we were able to leverage parts of the old data model to translate into the new one.  This made it easier to right-size the work for our remaining sprints, and we could use our retrospective to discuss the tradeoffs that would entail.  Each stand-up of that sprint was interactive and engaging, with information and decisions being made every day.  The members of our team working on the next data acquisition were benefitting as well, understanding the new model, so that when the next integration phase came, it would be seamless.   By the third sprint demonstration session, we had a completed design and framework of a basic data model that was much more user-friendly in our test environment.  It would work with new data acquisition, and was robust enough to handle changes to the way the transactional engine worked as well. This was a plus knowing that the system could change in its infancy.  Result We were able to develop and deploy the completed BI product 10 days after the transactional engine went live, well within the two-week window we were given at start.  A good thing too, because the business intelligence revealed multiple pain-points with the transactional engine that was corrected in the first three months of activity before they became widespread issues (because it was developed under an Agile SDLC too!). Because everyone on this Scrum team had previous work experience and training in Agile, when our major defect was found, I noticed three things:   Everyone demonstrated positive and value-adding insights because we were using Agile tools both before and after the issue discovery.  There was no finger-pointing at who caused the problem, no wasting time on reiterating goals or expectation, or on additional root causing and over analysis of the issue.  Everyone leveraged their role and their cross-functional knowledge to acknowledge, overcome, and advance on the right path forward. We determined and fixed the problem very early in development, instead of waiting until a comprehensive testing window near the end of our product for it to be revealed, which would have been an even bigger issue and more rework with all the additional data and features built upon and with dependencies on the core data model. There was very little impact to meeting the project deadline. Even more so, the additional value and learning of our product due to “fast failure” influenced productive, rapid adaptation to build the “right thing”.  
Rated 4.0/5 based on 20 customer reviews
Fail Fast: A Case Study of Agile Correcting on-th...

Everything about Agile Methodology revolves around... Read More

other Blogs