This is the age of packaged applications that quickly solve business problems, promising fast time to market or deployment. Articles found across formal business journals, popular business magazines, and technical blogs call out speed of delivery and customer interaction as the mantra for enterprise software implementation.
Agile methodologies (and there are several) are often used by software developers to deliver the latest applications. Because of the flexibility and collaboration sited from an agile approach, these methods have become preferred during software development or implementation.
But if these Enterprise Performance Management (EPM) and Business Intelligence (BI) enterprise technologies are so “out-of-the-box,” does project methodology really matter that much? The short answer is a resounding, “Yes.”
And how much attention do you really need to pay when evaluating an implementation partner? A lot.
In fact, it’s one of the major check boxes in our Checklist for Evaluating Implementation Partners.
You know that, no matter how streamlined your new technology is, you’re going to need customization and an expert who knows how to implement your application in a way that makes sense. If an implementation partner uses a specific methodology, it’s because they’ve been honing it for years and they know that it works — no matter the project. But, you also need to make sure their methodologies match the requirements and expectations of your organization.
While evaluating implementation partners and their corresponding methodologies, you’ll come across three, including…
In this blog post, we’ll briefly describe each methodology and which method we’ve found that aligns most with what customers look for and expect from a professional EPM/BI services firm.
The waterfall methodology is the traditional approach to implementing and designing enterprise systems. Within this methodology are typically 5-7 phases (depending on who’s implementing your technology), these include something like…
- Define (Requirements gathering)
The process is completely linear – you don’t move on to another phase until the previous phase is complete. With this method, everything is clear and organized with designated steps. It’s easy to maintain and you should come away with clear and comprehensive documentation. It also has less customer involvement, with most of their time spent in the requirements gathering phase.
However, the inflexibility can make it difficult to make changes — you’d have to start the entire process over again. You’re also typically looking at longer deliverability times. And, as a customer, the speed of delivery means the more time you can utilize the software you’ve invested in. But, keep in mind, you need a solution that works correctly within the context of your organization.
The agile method is as flexible as the waterfall method is rigid. In fact, flexibility and experimentation is encouraged within the agile method.
There’s a lot of customer involvement in this method with frequent reviews and collaboration at various increments. You’ll have the same 5-7 phases within the agile method, but the execution of those phases is somewhat loose, and organized in “sprints.” The sprints have a specified duration with a list of deliverables that you plan at the start of the sprint. This method allows the customer to have more visibility and a stronger sense of ownership of their solution.
But, this also requires the customer to have someone from their team entirely dedicated. You’re moving quickly within the agile method with can cause stress associated with users and stakeholders having to frequently weigh in, disrupting their workdays.
As with anything, there are pros and cons with each method. However, there’s an alternative, taking the good from each methodology.
The Key to Successful EPM/BI Projects? The Blended Methodology
There are three key words when you talk about EPM or BI projects: expectations, timeline, and cost. The underlying theme of is desire for structure and no surprises — much closer to a Waterfall methodology.
EPM and BI projects are framed by vendor software. Though customers may have strong grasp of business logic, they might be new to analytical tools and need to see data to finalize the logic concepts. This leans towards agile methods.
Because of both of those themes, the best methodology for an EPM or BI project is a hybrid, or blended, approach of the waterfall and agile methodologies. But what does that mean? And what does it look like?
The front-end activities, Define and Design, are best addressed using Waterfall. It ensures that requirements well understood, documented and agreed upon. Once that’s translated to some sort of document to trace deliverables, priorities can be assigned — which flows into the Design phase.
Using the documentation, project leads define architecture requirements and guide the development team to identify the build objects and then organize the backlog into sprints. (Notice our language has shifted to agile.)
In a blended method, waterfall is used in a project plan phase, but the build and test sections employ multiple sprints. Waterfall phases define the major time blocks, while the sprints define the bundle of work.
While each sprint is a milestone, the sprints can’t be so rigid that features cannot shift between sprints. After all, it is delivering the complete solution that is important. In the true agile spirit, sprints will allow for deeper technical and business understanding. However, in keeping with the waterfall method, scope control and change control must be enforced.
Adopting a hybrid Waterfall/Agile project methodology provides the requirement rigor and cost structure that customers need.
At a high-level, the waterfall methodology frames the timeline and major phases. Agile methodology provides the quick turnaround to keep the customer engaged, driving user adoption and clarifying fuzzy interpretations. Agile plays to the strengths of your implementation partner — small teams of highly experienced process and technology experts. The hybrid methodology reduces risks by clearly describing requirements and creating the backlog — iteratively delivering usable components to uncover “surprises” sooner.
In addition, the blended method gradually builds user familiarity with the solution and technology making change processes smoother.