Using #DSDM #Agile project management methodology to deliver a #SAP #BI Project faster

[MGrob]

Read how agile project methodology can help you deliver a BI implementation faster to the business users.  With an agile project methodology your business users will have the application earlier than with traditional project management methodologies, guaranteeing you a faster return on investment.

At the same time, it will help develop the application faster and "leaner" with less iterations and unnecessary code. 

The Project - and the trouble with the traditional project management approach...

Imagine the requirement is to create a quarterly forecast application within Integrated Planning.  The application needs to be ready for the first estimate cycle, in about four months time.  As a result, you have less than four months lead-time to document the requirements, write the specifications and implement the solution.  Don`t forget that within that time period, you will also have to train your end users.

Within these tight timelines, the above could not have been executed without compromising the quality of the tool.  As with all projects, the requirements are pretty vague and undefined at the beginning and it takes endless iterations until you have the full scope and the blueprint written. With the traditional project methodology, completing a "big design upfront" of this magnitude will take half of your project time, jeopardizing the time needed to implement the solution. 

What is so great about DSDM Atern agile?

If you are not familiar with the DSDM principles you can read up on it here…

The initial "design a quarterly forecast tool" project scope or definition is almost enough as "terms of reference" to leave the pre-project part of the deliverables.  Completing a feasibility assessment and creating an outline plan does not take up too much valuable time, as we limit the approach to just "enough design upfront".

What`s "enough design upfront"?

Well, this depends on the project size but in our "case" it means we don't try to "nail-down" every business requirement at this point, just to produce a blueprint that gets haunted by several change requests (because business users weren't able to make up their minds) or simply have not enough imagination to envision how the tool look and what is possible from a technology perspective. 

Foundation

Leaving the foundation we have created a prioritized requirements list which describes the requirements, but still defined at a high level.  This is contrary to following the traditional project management approach where the points listed below would first be defined in detail, while with the agile approach we just prioritize those according to MoSCoW. 

Prioritized Requirements List:

- We MUST HAVE the ability to plan sales, quantity and ASP;

- We MUST HAVE an application that shows actual data from past months and allows the user to enter forecast data for the rest of the financial year;

- We MUST HAVE the ability to integrate the forecast into existing BW reports;

- We SHOULD HAVE planning functions that assists in building the estimate based budget reference data;

- We SHOULD HAVE a planning function to extrapolate actual results;

- Those SHOULD HAVE dependencies automatically calculated;

- We COULD HAVE an option to apply seasonality of sales;

- We COULD HAVE a planning function to copy forecasts.

We also create a delivery plan sorting out the key milestones and the dates associated with each increment. With the looming deadline of the first forecast period in 3.5 months, the first increment contains 3 "Time-boxes", each 4 weeks long.

Exploration and Engineering

Time-box One contains the backend setup in BW, designing the cubes and acquiring the data required for the application.

Time-box Two contains the two "must haves"… once completed, we basically have the actual forecast application ready to be deployed.

The third Time-box holds the requirements for both reporting and the dependency automatically calculated.

Deployment

After finishing Increment 1, the solution is deployed, allowing us to deliver the application to the business users on time.

While none of the planning functions have been developed, the application is ready to use.  Thanks to some modeling and option exploration, the solution is consistent with the business users original request. If you not involve business intensively in the development, you are more likely to create a tool that has little buy-in from your actual customers and you are more likely redevelop certain pieces.

Comparing this successful outcome to a traditional project management approach, under the traditional approach we would not deploy the solution at this point, but rather first finish developing the full scope project.  These remaining requirements, however, would have caused us to miss the deadline for the first estimate.  As a consequence of time pressure, we could have possibly cut corners or further compromised the result and quality of the tool.

Instead, using agile, the application reached a deployable state after increment one by delivering on time.

Increment Two contains the remaining features split in two "Time-boxes". For the second estimate cycle, all planning functions can be developed and deployed.

Conclusion

With an agile approach you will have any BI project faster "up and running" and sooner delivered to the business with leaner implementation effort.

You also do not need compromise quality and instead of delaying the go-live we simply made the delivered features a variable.