Are You Wasting Time and Money on Bad Planning?

The project itself probably isn’t what’s taking most of your time. Sometimes, 80 percent of a project is in the planning. Engineers consider features like asset conditions, systems, crews, vendors and workflows, then the costs of each.

But what if you could plan with twice the focus in half the time?

If you think it’s too good to be true, consider this:

On the surface, planning is easy. You incorporate triggering events among human and systems actors into a swim lane, then build out a functional decomposition to show the individual elements of a business process. From there, you can estimate the time and cost for each business process.

It’s scaling this, however, where cracks tend to appear, resulting in challenges during the implementation.

Why Something as Simple as Planning Often Proves Difficult

Perhaps the planning process works well for projects that cost between tens of thousands of dollars to the low millions, with durations less than a calendar year.

But the process may not be consistently applied, nor well understood across stakeholders. Results may not spring from project objectives because of misaligned expectations, unexpected issues, perfectionism, stakeholder demands or scope shifting.

Whatever the case, it might seem intuitive to hold working sessions that extend daily over weeks or months, with too many semi-contributors not fully contributing or engaged to the end.

For example, what better way to avoid misunderstandings than to lay out all aspects of the project unambiguously for both project managers and business analysts? After all, both are charged with meeting project objectives, developing goals, identifying risks and developing strategic plans.

Right?

Wrong.

While project managers and business analysts have similar roles, they differ from one another in key areas.

Project managers manage schedule, cost and scope. Business analysts develop work breakdown structures (WBS) and tasks, elicit requirements from stakeholders and subject matter experts (SMEs), and manage the information that comes from them.

Consequently, bringing the two together for an eight-hour session not only eats up a huge chunk of their time, it at worst can cause the very misunderstandings you’re trying to avoid.

For a superior method, consider this.

How to Rapidly Improve Business with an RPM Approach and Block Schedule

In a nutshell, the challenge to large-scale planning and estimation is scope management. Modeling working sessions after a Rapid Process Map (RPM) block schedule can save time and money.

With the RPM approach, you’d engage four hours per day across two sessions, with a focus on having the right people in the room, rather than incorporating everyone all at once for the duration. This could potentially cut the time in half and lead to more focused work sessions with aligned and communicated goals. Employees could keep up with their day jobs, yet engage fully during the work-sessions.

The result — a solid scope management plan and a requirements plan.

The scope management plan would document how the project scope will be defined, validated and controlled. The requirements plan would describe how project requirements will be analyzed, documented and managed.

Next would come the process of implementing your project objectives.

How to Guarantee Results by Detecting Hidden Scope and Technical Issues

With planning, a five-step Initial Estimating Sprint Zero can achieve a 75 percent confidence level. The five-step approach provides early detection of “hidden scope” and technical issues.

The five steps include Scoping and Prioritization; Decomposition; Abbreviated Impact Analysis; Budget Estimating; and Initial Program Planning.

  1. Scoping and Prioritization considers core objectives, phases and key dates.
  2. Decomposition breaks down high-level processes into individual steps and systems.
  3. Abbreviated Impact Analysis identifies and prioritizes features and reports, tying the features to the objective.
  4. Budget Estimating considers the cost of implementing these features based on the amount of hours they will take. A top-down approach is most effective here. Start with epics, which are a collection of user stories usually short on the details. Then work down from there.
  5. Initial Program Planning tunes financial estimations by engaging all the user stories from the bottom up to determine options and potential savings.

Daugherty RPM is Daugherty’s trademark innovative approach to handling large-scale estimation. We can provide a faster, better and cheaper solution with our approach, which has been proven in our success with large-scale organizations like Anheuser-Busch, The Home Depot and MasterCard. Whatever size estimation you need, Daugherty can deliver. Contact us today.

Making Your Business Intelligence Team Agile

So, you think you can’t make Agile work within your business intelligence team?  Think again.

Agile business intelligence isn’t new; many people have written about it.  It’s mature enough now to have a smattering of books lining the shelves. What are these books based on? Experience. People are executing it and have been for some time.

At Daugherty Business Solutions, we have a group of those experienced professionals on our team. In fact, we have worked with a large telecommunications client for fourteen years using parallel Agile sprints to support enterprise financial performance reporting. The group in place has evolved from large teams to manageable teams of eight, and members have cross trained between ETL and data visualization tools.

The evolution of these teams was not an accident, but instead an orchestration of the Agile methodology. Some people may think of the term Agile and wonder if that applies to business intelligence in the same way that it does application development, and there is no doubt that there is a difference between the two. But, the specific factors differentiating these doesn’t need to be standing in the way of organizations realizing the benefits of using Agile principles to bring more value to their customers, more quickly, and with less overhead.

So, how do you do it?  Before making that determination, there are two key things that need to be identified.

First, data projects are different. You have to acknowledge it.  Sing it from the rooftops! Just like we cannot use exactly the same team and methods to successfully execute a Waterfall application development project and a Waterfall data project, we certainly can’t use the same team and methods to execute an Agile application development project and an Agile data project.

For example, Team Daugherty is working with a cable company’s business intelligence group to build Agile capabilities into their current teams. As we launch projects with them, we’re working through our planning sprints and introducing an additional sprint to allow for some of the coordination and planning required when implementing projects. This is important when using full enterprise data stacks and fully mature data warehouses. By planning more up front, we’re able to fully implement Agile practices, and we are seeing an extremely positive response from our business partners.

Second, because information management projects are different and have different players, characteristics and challenges, we’re going to have to let go of some of our purist notions of Agile.  Think for a minute about this question: what is Agile at its core?  Is it ceremonies?  Is it a product backlog? Is it cadence? Agile is not one of these things. These are all things we do within specific Agile methodologies. To be Agile is to generate value for the business in a consistent, timely manner. The rest are just rules.

Does this mean that we want to throw all of these guidelines out the window? No! What it does mean is if a particular rule is preventing us from achieving our goal of realizing the benefits of Agile, we should evaluate it for validity within the information management discipline and weigh that against how that particular rule helps teams realize specific Agile benefits.

This is true for a number of the projects we are working on right now. One that is top of mind is a project that has Daugherty working with the business intelligence group at a retail client to define how Agile principles will be applied on their teams. As we know, one size does not fit all. In this IM project example, unlike application development projects, it does have some stories that must be executed in a specific order. Working together with the client’s teams and product owners, we’re redefining how the stakeholders prioritize features and the value produced in each sprint, knowing that some of our work items must be executed in a specific order. It may be a specific Agile rule that work items are designed to be interchangeable and can be re-ordered at any time, but we know that, in this situation, that is not what is going to lead us to be the most successful.

Just remember, we’re going to have to let go of “purist” rules and methods, weighing them carefully against the value they bring. Through our work we know that it has to be okay to sequence some work items in a specific order to deliver value to the business.

When working as a part of an Agile team at Daugherty Business Solutions, I have learned that we value “value” more than rules.