Six Steps for Stress Free Software Delivery


Introduction

Technology projects are often associated with exceeded budgets and missed deadlines. Relationships with suppliers often deteriorate and rumours of legal proceedings abound, and yet there are some projects that go smoothly and certain suppliers who get hired again and again.

Delivering a complex technology project into a large organization can be a nightmare, but it doesn’t have to be. The multitude of systems, people, and processes can hamper progress and amplify problems at every stage, but these issues can be avoided. There is no quick-fix, one-size-fits-all solution to these problems, but there are many simple things that can be done to make things run a bit more smoothly.

This document presents six steps to help business leaders to alleviate the stress of engaging with a software supplier and of managing the software delivery process.

Select your supplier using common sense over process

Bob and Carol run a flower shop. They are looking to select a supplier to implement a website for their business. They ask their friends for recommendations, put together a shortlist of suppliers, look at examples of their work, and have a chat with the staff responsible for that work. After a couple of weeks and an investment of no more than four hours effort, Bob and Carol select a supplier and development work begins.

Bob and Carol work next door to MegaCorp, who started as a small business, but grew to hundreds of employees. As the business grew from its humble Bob-and-Carol-sized operation to the large enterprise that it is today, MegaCorp also added new layers of management. Despite the senior management’s best efforts, the results-driven culture has bred an environment that is highly competitive and unforgiving. Each manager, terrified of making an incorrect decision, has become obsessed with creating and following processes and a culture of bureaucracy has prevailed.

MegaCorp also wants to build a small website for one of their many subsidiaries. Making quick decisions based on common sense would be an unthinkably risky approach to supplier selection at MegaCorp. Instead, they have implemented a rigid RFP (Request for Proposal) process backed by over 40 documents. It took 28 staff over four years to develop the MegaCorp RFP Process™ and everyone up to senior management was really pleased with the end result.

MegaCorp ran their RFP based selection process. Over a period of two years they selected the biggest consultancy in town. The project is ongoing. Nobody knows if it is on track, how much it is costing, or when it will be finished.

This fictitious story illustrates a common issue with the supplier selection processes, one of many rigid processes that can appear within large organizations. Mention the phrase “RFP” or “tendering process” and most people will let out an involuntary groan of despair as they ponder wasted hours completing excessive documentation, navigating complex processes, and trying to penetrate an impassable matrix of stakeholders.

For Bob and Carol, the total investment of time in selecting a contractor was minimal. The process was very efficient, undocumented (or at best documented only in short email communications) and fast as there were only two key decision makers in the process. This is a highly effective process for making a reasoned selection of a supplier. It is a process based on common sense that completely lacks any bureaucracy.

In contrast, MegaCorp created a process to select the “least risky” supplier. Time and time again we hear of late, over-budget, wayward projects that have occurred despite a lengthy supplier selection process. Why?

The problem with a highly contrived tendering process is that itis ultimately a meaningless corporate courting ritual where the organization with the people who are best at winning tenders is usually successful, not the organization with people who are best at delivering projects. The supplier with the best team to do the job is rarely selected.

So the first step is to be more like Bob and Carol and less like MegaCorp. Make a supplier shortlist (noting the prefix “short”), document your requirements clearly and concisely, speak to potential suppliers’ existing customers, and then to the actual project team that will work on the project – not their salespeople or inspiring CTO. Talk with the team that you will be working with for the long haul. Even if you are ultimately forced to follow your organization’s official procurement process, use a common sense approach – make a sensible analysis and incorporate this into the official process. Ask yourself, what would a small business do? It will help you to inject some common sense into any company process.

Make a realistic timeline

Despite the best intentions of suppliers and their clients, the inescapable truth is that most projects are delivered later than originally intended. Careful and realistic planning is required to deliver any project to a meaningful schedule.

There is no magic solution to this fundamental problem, but itis possible to give your project the best chance of success by making a realistic timeline.

It may be tempting to request that the project is completed by June because you are going on vacation in July, for example, but this is an arbitrary deadline that may force suppliers into taking shortcuts to meet milestones at the expense of quality. It might also feel necessary to require that a project be finished by the end of Q1 because your CTO needs it done by then for the next board meeting, but sometimes you will have to accept evidence from multiple advisors that mid-Q2 is a more realistic deadline.

If a hard deadline is mandated as part of the tendering process, then it is in the interest of a supplier to agree to any timeline put in front of them. Saying that it will be almost impossible to deliver to a proposed timeline, when it is assumed other suppliers will be saying the opposite, would be a brave move and may well ensure their swift exit from the process. But you as a client must extract an honest assessment from all of your candidate suppliers to get a true sense of a realistic schedule.

Ultimately, you as the client will always set the timeline for when you will go to market. It is therefore essential that the proposed timeline is one that is independently verified as being achievable. Unless you are a subject matter expert and have experience of delivering the same solution yourself in the past, then this will mean consulting with suppliers in advance to get their opinion on timelines, rather than imposing one on them as part of the tendering process. You may even consider bringing in a third party consultant to verify whether the bids are realistic.

Perform analysis and design work before engaging with a supplier

It is imperative that before engaging suppliers and entering into a selection process, that the project’s vision, requirements, and high-level solution is defined in sufficient detail. For Bob and Carol, that might mean sketching a wireframe design for their site. For MegaCorp, that might involve a more structured technical design process.

A common misstep is to enter into a tendering process without sufficient clarity in the RFP. If the bids are wildly different, then this is a clear indication that the requirements were not particularly well defined. This leads suppliers to make their best guess based on the information available and to cover themselves with a myriad of caveats. If you find your project in this situation, put the process on pause and dive into a round of analysis and design before improving and re-issuing the RFP.

To achieve the depth of planning and analysis that will significantly increase the chance of success, it may be necessary to engage a supplier to help define requirements and technical details of the project. It might seem counter-intuitive to have to select a supplier to help with design, ahead of potentially selecting another supplier to complete the implementation work, but it is a good way to ensure that the right level of detail is available for the next phase of the project. It will mean that more accurate timelines, cost estimates, and better fit solutions are proposed.

Be engaged

Don’t expect to sign off on a contract and then wait patiently for the output. Once you have selected your supplier it is important that you, as the client, become an integral part of the delivery team. A high level of commitment is required to help shape the direction of the project.

This is not the same thing as project managing the project, which should certainly be the responsibility of the supplier. But being available, committed, and involved in decision making on a day-to-day basis will be one of the key drivers in achieving the desired end result.

Whenever you receive a key deliverable or reach a project milestone, engage in a project review with the supplier. What is their assessment of the project at this point? Are there any further details which are necessary to complete the next milestone, or anything else that you as a client can do to help keep the project on track?

Bob and Carol from the flower shop would be highly engaged in their project, because it’s their passion and livelihood. The employees of MegaCorp may have many more dependencies and distractions, but they will also have more resources. Pull in stakeholders to engage in the project.

Be prepared to walk away

Having expended so much time and effort on selecting the right supplier, you will naturally want things to work out. That’s why it’s all the more disappointing when things start to go astray. If they do, you may have escalated all the way up the chain, and voiced your frustrations to anyone that would listen. Perhaps you even threatened legal action, but ultimately things might just not improve, whatever you do.

Perhaps the senior people that you spoke to in the initial meetings with the supplier have all disappeared, being replaced by apparently less capable team members. Or perhaps you find that the supplier is just out of their depth and struggling to meet your needs despite their best intentions. Whatever the reason, if things start to go wrong, and if it’s clear that things aren’t going to be made right, then it’s time to take decisive action.

Of course, you want to fix the current relationship if at all possible – handing over to a new team can be equally risky and doesn’t guarantee the immediate success of your project. So, it’s a brave decision that is required to switch suppliers, or at least walk away from the current agreement, but often that is the best course of action. Continuing to work with a badly performing supplier will be stressful, frustrating, potentially costly if you are paying for delays, and will ultimately lead to a poor product being delivered.

Whether you are Bob and Carol or a director at MegaCorp, the best thing to do in this situation is to walk away and change supplier as soon as possible. The longer a bad relationship continues, the more poor quality deliverables and bad code that will be produced. This will result in mounting “technical debt” that needs to be tackled in the future. It will be costly and could impact the perception of your business if you are developing a product that is used by your end customers.

Don’t cut corners

If you are building a software platform, a website, or a mobile app, you may only be interested in whether a supplier can deliver this to you – your idea realized in a tangible form. You may not be interested in the code that made the solution reality and may be even less interested in the processes that are used as part of development, but you should show an interest in these details as they will save you money in the long term.

It is extremely common to have an amazing looking software product or digital platform that is actually a terrible mess behind the scenes. What this means is that although you and your customers may be happy with the results, you will find that making changes and identifying issues seems to take an unreasonably long time. This is the result of cutting corners during the software development process.

Further down the line, this corner cutting will continue to plague the project. You may start to doubt the effectiveness of the development team, even though they seem engaged and reply to your emails promptly, so it can’t be that they are lazy. In fact, they aren’t lazy; they are just struggling to tame the beast that they created, now pouring through thousands of lines of code to find the needle in a haystack that will resolve a bug that should be trivial to fix.

On top of this it may become mystifying as to why the delivery of new software (“deployments”) takes so much time and seems to be unreliable and risky, often breaking things, despite extensive prior testing showing that everything was working fine. This is a problem caused by insufficient investment in software development tooling, infrastructure and process. Setting up “DevOps” processes and infrastructure (such as Continuous Integration / Continuous Delivery) and running proper software development processes (such as using test automation) is work that you pay for that ostensibly generates no tangible output, but putting these in place at project inception will save you time and money, many times over, during the course of an engagement.

If a supplier is not urging you to put processes like this in place, and allows you to cut them from the project to reduce costs or compress the timeline, you may question their suitability. Bob and Carol’s small website for their flower shop probably does not need test automation or continuous integration, but software for MegaCorp certainly does.

Conclusion

No one wants to go over budget, miss deadlines, and create stress within their company. However, those are the results of ineffective software delivery. Time devoted to avoiding all too common errors will result in lower costs, a predictable schedule and better working relationships across the teams who are involved.

Here’s a refresher list:

  • Don’t use an overwrought process, use common sense
  • Don’t demand or accept unrealistic timelines
  • Don’t take shortcuts with the project design phase
  • Don’t rubber stamp the deliverables – engage with your team
  • Don’t be afraid to halt work with your current resource and find a new team
  • Don’t cut any corners, budgetary or otherwise

Please reach out to us at Priocept if you are in the midst of a stressful software delivery project and need some impartial advice.

Leave a Comment

(required)