Six ways to simplify decision making in projects

4 November 2014

John Hannah

John Hannah

Consultant

Do your business users struggle to make the design decisions that the project needs? Here’s how the project team can help them.

What are the critical success factors for a successful project when implementing a new process or system? The answer has been drummed into us many times: clear sponsorship, effective governance and business change management, well defined scope and so on. There is no shortage of top ten lists of do’s and don’ts for how to build and implement software solutions.

Knowing this does not necessarily make it much easier; most of the time it is still a challenge to deliver on time, on budget and to ensure realisation of the benefits identified in the original business case. After all, if it was easy to achieve, then maybe we wouldn’t need to organise a project to do it…

One thing that most of the top ten lists agree on is that it is rarely “technical” factors that are a major cause of project failure. If the software and technology are proven, and if the project has engaged experts with appropriate technical skills, then that part normally works, at least most of the time.

Here I will focus on one aspect that is a common cause of project issues and delays, even in projects that are otherwise well structured and well scoped. That is the effectiveness of decision making by the business users. I will explore the reasons why this is can be an issue, and I will offer advice on what the project team can do to minimise its impact.

Dithering design decisions = damaging delays

During the implementation of a new solution, there are many occasions when a business decision is required on elements of the design. Whether the new system is custom-built, or based on a software package, there are multiple design options open to the system architects and developers.

Simple examples of where clarity on requirements and design is required include:

  • Business process flow and functionality
  • Scope of master data fields and groupings
  • Approval steps and workflows
  • Report content and layout
  • System roles and authorisations

Naturally most projects start with some form of definition or blueprint phase which identifies “the business requirements”, which then act as a guide for the build team. In most cases, the business users have a good idea of what they want, but they don’t know the full capabilities of the software. The system experts know what the software can do, but have limited understanding of the business users’ real needs and priorities.

Dialogue on this must be a 2-way process in order to optimise the outcome. If the focus is too much towards meeting the stated “requirements” exactly then that may lead down the path of costly bespoke development and failure to take advantage of opportunities to simplify and standardise. Conversely, if the solution is too software-driven (for example via a pre-configured “accelerator” template), then there is an increased risk of user negativity and resistance. In order to achieve the kind of outcome that most projects are seeking, there must be some give and take on both sides.

But even a well-defined Blueprint does not nail everything down in terms of every detailed business requirement. There are still many individual design decisions that need to be made as the focus moves from the requirements definition to the build phase of the project. And this is where problems can start if the business representatives are unable to provide the required design guidance within the timescales that the project team needs to keep progress on track.

Be alert to the warning signs

It’s not difficult to spot the warning signals when important design decisions are either absent or arriving too slowly. Some examples of typical comments commonly heard in project team conversations include:

  • “I am waiting for the business to decide on this”
  • “We are waiting for someone to clarify what the requirements are”
  • “We don’t know who the process owner is for this”
  • “Our key user is away, so we have to wait until they return”
  • “The business can’t agree on which option they want”

Sound familiar? We have all heard such comments on our projects. Sometimes we start to take them for granted. But each one represents a potential delay to the project. If the missing decision relates to the design of a key integrated process then this can have a major impact across multiple streams within the project, including development, testing, and data migration.

Just to take one example – the design of material group categories for purchasing spend reporting. I have seen one project where the list of required categories was agreed in one workshop session. In another project a similar design decision took nearly two months.

Business users are busy people. It’s not that they don’t want to make the design decisions that the project team needs. It might be because they are too distracted by other priorities, or maybe it’s because they don’t have enough information to help them make the decision. They might even be scared of the consequences. Whatever the reason, the project team needs to do something to help them.

It’s the project’s problem, not the business users’ problem

When this scenario arises, the worst thing that the project team can do is to do nothing. It may be tempting to sit back and wait. It is the easy option, especially if the project team has already sought several times for a decision on a design question. Yes – maybe the business representatives are not fulfilling their role effectively – but it is the project that will suffer the consequences, and it is up to the project team to do something about it.

This is best done by being pro-active and giving the business representatives more information to make it easier for them to understand the options and then make a decision.

There are many ways that a well-drilled project team could approach this in a pro-active way:

1) Introduce agile methods

Adopt a more agile and collaborative development approach to shorten development timescales and increase the number of touch-points with the business users. The more they see of the emerging design, the more easily they are able to articulate what they want. Agile methods provide more opportunities for prototyping and iteration, and help maintain alignment in direction and expectations between the team and the users. This makes it easier for the users to make the design decisions that the development team needs. 

2) Increase dialogue

Organise opportunities to discuss the scenario with the users in more detail to get a better understanding of their needs, and of the underlying business context. Don’t just rely on some requirements document that perhaps was written some months earlier. Things will have changed since then. The more the analyst or developer understands, and the better the quality of the dialogue, the easier it is to agree a mutual decision on the optimum design.

3) Demonstrate experience

Make the effort to illustrate the design options with evidence and experience from other similar scenarios on previous projects. Be assertive in offering advice rather than re-active, and challenge the status quo where necessary. In most cases the analysts or consultants involved are perfectly well aware what the “best answer” should be. But some may be less inclined than others to offer or appear to impose their views on the matter.

4) Use a decision matrix

Create a matrix illustrating showing 2 or 3 alternative solution design options and add some categorisation to highlight the relative pros and cons of each, ideally with a recommended preferred option. This provides a simple one page summary for the decision makers. In most cases this proves quite sufficient to enable them to quickly agree a preference – and nearly always for the option that the project team has recommended. This can be a simple and very effective way of clearing a log-jam of outstanding design issues.

5) Delegate the decision making authority

Ensure that key decision makers, such as process owners, also have authorised deputies, who are empowered to take decisions on their behalf. This gives the project team a greater chance to avoid delays caused simply by the absence of key people. It would help also for the project team to be aware of impending absences of key participants; it is surprising how often simple issues of this kind can cause project delays and inefficiencies. 

6) Instil strong governance

Apply strong protocols. For example, agree that, if necessary, in the absence of clear direction from the business decision makers, the project team can take design decision themselves, making sure that this is clearly documented, so that the project can move on. Such decisions are usually appropriate, and the business users can be advised, and given a (brief) time window to make an appeal. Agree early on that as a project “standard” every required design decision must be made within a maximum 1 week time window, and then ensure that this rule is observed as the project progresses.

Don’t delay - decide today!

Don’t let decision making issues be a drag on your project. Be alert to the warning signs and take pro-active steps to address them. Don’t do nothing and wait, and don’t blame others – this just causes more problems for the project in future.

Consider this to be the project team’s problem, not the business users’ problem. Assume that the business users are unable to decide because the project team has not given them enough information – and give them more information to make it easier for them to decide.  And if that fails, then make the decision on their behalf, document it, and explain the consequences.

“Isn’t this all just common sense?” you might ask. Yes of course it is, which means it should be quite easy to do, and also that there is little justification for not doing it.

The only reason for mentioning it at all is that it seems to still be a common problem for many projects, and it need not be.

 

View comments

Comments

Blog post currently doesn't have any comments.

Bluefin and SAP S/4HANA - welcome to the one horse race