Hybrid approach to Projects will deliver a better result for your customer

Taking a hybrid approach to projects will deliver a better result for your customer.  Over the last 20 years, most software companies have adopted agile approaches to managing their dev or internal projects.  It made sense, agile was more responsive than waterfall and allowed companies to get further faster.  By breaking projects into iterations the team was able to make the conceptual leaps, see results quicker, more actively drive priorities and get in the habit of making frequent decisions.

So why don’t all software companies take an agile approach with customers?

The disadvantage of an iterative approach is that it’s quite difficult to manage scope and timeline. Agile projects can easily go on forever without an end, in fact, that’s kinda what they are engineered to do. This is great if your customer has infinite money and time, but these days most customers want a risk-mitigated approach and budget certainty. They also want to know how long it takes to get value from their investment.

Enter Hybrid Approach

Hybrid project methodology provides the best of both worlds. It uses the planning precision and structure afforded by a waterfall approach, while also providing the benefits of sprint-based approaches. TekStack recommends software companies apply a hybrid methodology to their project delivery. It works exceptionally well for your customers (especially if you operate in a low code world) because:

• It provides a clear expectation of timeline and effort at each stage of the project.
• Instead of getting buried in project phases like analysis and design (which provide limited value to the customer), it accelerates this stage and gives customers something to look at very early so they can participate in the final design.
• It solicits feedback from customers but still limits the amount of time spent on configuration or customizations.

Here is an example of how TekStack approaches our own customer projects. It provides enough granularity while not inundating a project plan with ‘to-do’ level tasks.

In this screenshot, we see a work breakdown structure that is typical of waterfall-based projects:

• Planning
• Testing
• Training
• Data Migration
• Go-Live

But in the middle of the project plan (and oriented very early in the project timeline) we see a Project Task called Configuration. In this example, there are three iterations of configuration, plus one regression iteration that occurs in the testing phase (not shown in this screenshot).

By structuring it this way, the PM can establish a timeline, that there are three iterations of a weekly sprint, set expectations for effort, and plan accordingly.

When should Sprints start?

The sprints begin after five things happen for the customer:

• A preconfigured software environment is set up and seeded with basic data so that they can relate their world to the solution. The customer should be able to freely log into the environment at any time to play around.
• Provided with a system overview walking through key use cases.
• Given a list of gaps or requirements based on what they’ve seen in the overview.
• Receives an analysis and design document that summarizes how the requirements will be met. This may include wireframes, etc.
• Review any product gaps so they are in a position to stack/rank priorities.

Capturing Priorities

The priorities should get captured as ‘work items’. Do this in a spreadsheet, Jira, Azure DevOps; or use TekStack’s handy dandy Work Item feature shown below. The work items should capture some basic information like a description, application area, user persona reference, priority, and rough effort.

Once the work items are available it’s time to start assigning work to the sprints. Here you work from a couple of constraints. First, how much capacity you have in the sprint. This is based on the resources available, the length of the sprint. Second, how much effort is capped in the budget. Prioritize the efforts in order of high priority and high effort knocking out the ‘big rocks’ first.

Assigning Work Items for Hybrid Approach

A work requirement will have a skill or role dependency. For example, you wouldn’t give dev efforts to a junior application consultant, or finance requirements to someone who doesn’t have the skills. TekStack maps the requirements to the scheduling engine to find availability matching skills with availability.

Tracking Work Items for Hybrid Approach

Your Project Managers will want to track two things.

1) The Progress of the work items. Which ones are active and in progress, which needs to be assigned, which have been completed and validated by the customer.

2) How much time the team is spending on the work items. For each work item, how do actual hours compare to estimate? Note, your team will want to be able to track time against specific work items and ideally reconcile budget to actual.

Using Sprint-based approach for Managed Services Relationships

Agile not only work in these projects where you have an end goal for a project, but it’s a process that works really well in managed service relationships where a customer will continuously depend on your organization for new deliverables each month. The key difference here is that the customer needs an easier mechanism to request new work items, and be able to track or monitor the delivered work items as the months go on.

We built this into the self-service customer portal which allows them to:

• View the hours of effort requested, scheduled, and completed month over month.
• Track status of all work items
• Request new work items
• Add comments or attachments to work items interacting with the team who is delivering them.

Summary

A hybrid approach to projects will deliver a better result for your customer. It provides the structure required for project planning & budgeting with the flexibility required for execution. It works well for fixed-price deployments because it gives your customer assurance that not everything needs to be nailed down at the contract stage, delaying your deals, and shifting the risk to your organization versus having a balanced partnership approach to projects.