by Larissa T. Moss
It is not uncommon for seasoned project managers who use a traditional methodology on a DW/BI project to feel completely out of control. The requirements appear to be a moving target; communication between staff members takes too long; assigning tasks in a traditional way seems to result in too much rework; and so on.
To top it all off, the businesspeople are pressuring the project teams for quick deliverables (90 days or less) as they are still fine-tuning their requirements. As the project team scrambles to meet those expectations, data standardization is skipped, testing is cut short, documentation is not done, and quality is compromised.
But is it possible to do it right and still deliver in 90 days? Yes, it is. But you have to set aside some of the traditional project management disciplines and try a new approach.
Software release concept
While most organizations realize that they cannot build an entire DW all at once, they don’t realize yet that they should not build an application all at once either.
Why? Because the requirements are most likely unstable; the scope is probably too large or the deadline is too tight; some technology components might be unproven; data integration complexity is most likely not fully understood; not to mention the quality of the source data, which probably has not been vigorously profiled; the project team may be too small or too large or untrained; and the businesspeople are probably too busy to participate. With a project like this, you have to start prototyping immediately and keep prototyping.
But how do you prototype an entire application with its DW components without falling back into the waterfall sequence of requirements, analysis, design, coding, testing?
You break the application into multiple software releases. The scope of each software release will contain only a small portion of the application requirements, hence the name “extreme scoping.”
Each software release becomes a project. Each project is developed using an iterative prototyping approach. Each prototype is time-boxed, anywhere from one to three months.
Most software releases should produce a production-worthy deliverable, although there are occasions when you want to further refine [“refactor”] a deliverable in the next software release before putting it into production. After several software releases, you will have a completed and fully-functioning application.
The quality of the application will probably be higher with this agile approach because it allows the requirements to be refined with each software release until they become stable; the scope of each software release can be small enough to fit into a tight deadline; technology components can be evaluated early on; data integration complexity can be handled in small increments; the quality of the source data can be vigorously profiled because you will incrementally document the business rules; the project team can be small or even in training during the early software releases with minimal impact on the entire application; and businesspeople usually become more involved in prototyping activities than they are on traditional projects.
And the “icing on the cake” is that these types of projects are much more fun than traditional projects because of the different project team dynamics, which I will describe in my next article.
Software release planning process
Creating a project plan using Extreme Scoping is slightly different from the traditional way. Traditionally, the project manager reviews the methodology and selects the tasks that need to be performed into a work breakdown structure (WBS).
Using the WBS structure as a guide, he creates a detailed project plan, which is typically arranged in the sequence of the development phases of the methodology: requirements definition, analysis, design, coding, testing, and implementation. The detailed project plan is usually a 30-40 page Gantt chart, which is used to guide the day-to-day work activities, manage the change control process, and report the project status to management.
With the Extreme Scoping approach, the project management function is performed by a 4-5 member core team, not by a single project manager. The core team members also start out by reviewing the methodology and selecting the tasks into a preliminary WBS.
Using this WBS as a guide, the core team members create a high-level project roadmap to give an understanding of the overall effort, resources, cost, schedule, risks, and assumptions for the entire application.
This is necessary in order to come up with the right number of software releases, the right sequence of those releases, the dependencies among the requirements, and thus, the deliverables and scope for each release. Without this crucial step, the process of breaking an application into software releases would be completely arbitrary.
Once the core team members are comfortable with the scope and sequence of the proposed software releases and are confident that each software release is doable within the allotted time-box (deadline), they create a detailed project plan with weekly milestones for the first software release.
Starting with the deadline and working backwards, the core team members determine how far along they must be the week before the deadline in order to make the deadline. Put another way, they determine in what state the project or deliverable must be the week before the deadline.
They repeat that process by backing up another week and another week and so on. If they pass the project start date, the core team members must determine if the scope is too large for the deadline or if the time periods between the milestones are overestimated.
After the project activities for the first software release are organized into milestones, the core team members self-organize themselves into the appropriate number of work teams. Knowing the makeup of the work teams and knowing the weekly milestones, the core team members decide on the detailed tasks and task deliverables for each milestone, referring to the work breakdown structure they created earlier.
They also decide which tasks and deliverables are assigned to what person on what work team. The detailed daily task assignments and task deliverables are documented on a white board, a flip chart, a spreadsheet, or other informal media, which can be modified quickly and easily.
The core team members use this informal detailed project plan on a daily basis to guide the day-to-day work activities, manage the change control process during prototyping, and monitor the progress of the project. They do not use this detailed plan to report the project status to management. Instead, they create a short one-page Gantt chart showing only the milestones.
If the first software release was completed on time and without problems, the core team members can plan the second software release in the same manner.
However, if there were problems with the first software release, such as underestimated tasks, incomplete deliverable, friction on the core team, constant adjustments to the scope, and so on, the core team members must review and adjust the high-level project plan for the entire application. They must revisit their understanding of the overall effort, resources, cost, schedule, risks, and assumptions of the entire application.
Then they must make the necessary adjustments to the remaining software releases. That can include changing the scope for the second software release, changing the number of software releases, reprioritizing and changing the sequence of the software releases, changing the deliverables for one or more software releases, changing the deadlines, or changing resources. Only then can the core team proceed with the detailed planning of the second software release.
Conclusion
The popular concept of iterative development applies not only to developing the DW in small increments, but to the application level as well. Instead of organizing the project into the phases of requirements, analysis, design, coding, testing, and implementation, break the project into multiple software releases, i.e. multiple projects. Manage each software release by completion of milestones, instead of completion of tasks.
LARISSA MOSS
E’ una Senior Consultant nei settori della Business Intelligence e nel miglioramento della qualità dei Business Information Systems. E’ fondatrice e presidente della Method Focus Inc. Ha una esperienza di 28 anni nel settore IT, i suoi articoli sul Data Warehousing, Project Management, Information Asset Management e Data Quality sono pubblicati regolarmente su The Navigator, DM Review, Journal of Data Warehousing e Analytic Edge.
E’ co-autrice con Sid Adelman del libro “Data Warehouse Project Management” e con Shaku Atre del libro “BI Roadmap: the complete lifecycle” e sta completando il libro “Extreme ScopingTM: An Agile Approach to DW & BI”. E’ una frequent speaker alle Conferenze sul Data Warehousing e CRM negli Stati Uniti, Europa e Asia.
Presenterà a Roma per Technology Transfer il seminario “EXTREME SCOPING: Approcci Agili al Data Warehousing e alla Business Intelligence” dal 26 al 27 aprile 2010.
