millbrook_consultancy

Managing Software Budgets

Mon, 17 Feb 2020 14:32:00 GMT

Software projects rarely make headlines for being completed within original cost expectations (though thankfully it does happen). High profile overruns with large-scale implementations such as banking systems or outsourced government projects are well documented, but the challenges of keeping to schedules and budgets is also present for smaller undertakings. Creation of any new product is inherent with risk but why is keeping a software budget on track so difficult, and what are the factors that can influence this?

Conflicts Within a Project Team

This post is concerned mainly with delivery of a new product by a team working on behalf of a client (as apposed to say an ongoing development or post-MVP iteration). This may represent a software house working on behalf of a customer or an internal team steered by members of the same organisation. In either case there will often be conflicts between the various stakeholders, which may include: -

Customer ; often keen to maintain a fixed cost, perhaps pressured by budgets determined at board-level but will also have a strong expectation of what the product should achieve. The expected outcome (in their mind at least) may or may not be realistic for the budget.
Designers ; UX and UI designers will be passionate about the best possible experience and interface. Great designers know this means taking all stakeholders' interests into account but the desire to impress through visuals and functionality will be strong.
Developers ; often keen to use the latest tech, push their skills forward and demonstrate technical competency through refined code.
Users ; unless they have been well integrated into the design, development and testing process, users can unfortunately sometimes be an after thought. The needs of the user though are critical and frustration will surface quickly if not addressed.

The Role of the Product Owner

Holding a project together requires a strong team member to help manage overall delivery. Depending on the process being used, they may be known as a Project Manager or a Product Owner. This person will: -

Facilitate requirement gathering ; understanding the needs of the customer and assessing how this forms a requirement for the resulting software product.
Negotiate with the customer over scope and features ; initially at the outset when working with the customer to establish indicative budget and then throughout delivery to ensure features are deliverable and achievable.
Communicate decisions and priorities to the development team ; acting as a bridge between the customer and developers to help the understand the needs of project and decisions being made. This is not to say developers and customers should not directly interact (they most certainly should) rather the facilitation of understanding between the two parties is aided by this person.
Assist in testing and demonstrating work back to customer ; when a feature has been completed and ready for "demo", it is presented back to the customer.

Setting the expectation across the team is one of the fundamental requirements to help keep budget under control. By undertaking the role outlined above, decisions that are affected by cost can be discussed and fed-back to all stakeholders. This transparency builds a wider understanding of why decisions are made to help ease the conflicts within the team dynamic.

Start Small

Depending on the development approach being taken there are other considerations with respect to managing budget. For example, a "Waterfall" approach whereby the product development is tackled in sequential stages such as specification, design, development and testing will require very formal scoping and version control for a budget to be adhered to. An "Agile" approach, where requirements are expected to change throughout the delivery process necessitates a great deal of collaboration and mutual understanding between the delivery team and customer.

One method that will benefit both of these approaches with respect to budget is to simply restrict what is being delivered. Consider whether a section of the overall requirement can be costed and delivered initially. This presents an opportunity for all stakeholders to build an effective team ethic and understanding. This will benefit the product itself for the next phase of development when all involved have developed a more collaborative working relationship. As a result subsequent development is easier to estimate as expectations are more clearly aligned.

An Introduction to Minimum Viable Product in Software Development

Mon, 10 Feb 2020 12:38:06 GMT

The suggestion of a Minimum Viable Product (MVP) approach may raise concerns amongst stakeholders, particularly where they are not fully aware of the concept or have experienced bad results previously. When managed effectively however and with a clear understanding across the team then great value can be found.

What is MVP? (And What it's Not)

In its simplest form MVP is an approach intended to deliver working software at the earliest opportunity. One of the main purposes of this is to encourage learning and then to refactor the software to benefit from these learnings. The use of the word "minimum" can be a little misleading and imply that a lot of potentially great stuff is being left out. This isn't the intention, development does not halt once an initial limited release of the fuller vision has been delivered. Rather what is trying to be accomplished is identification of the earliest possible opportunity that the software can reach a usable state where feedback can be gathered, for subsequent stages to build upon.

Early Delivery and Learning

I've been involved directly in software development for a good while and have seen projects go well and not-so-well. Sometimes failures are hard to avoid but I've also seen projects that were ultimately successful through sheer will and an overwhelming desire to not reach a point of failure. Looking at common issues amongst these, I could highlight: -

A delivery date months (or even years) past the targeted release;
Mounting frustration between vendor and customer over costs or agreed functionality;
End-users rejecting the software;
Overwhelming support issues or emergency changes required by the development team upon release;

Often the common denominator amongst these can be attributed to a product launch that is not just ambitious but encompasses elements that are either not essential to the user or where iterative learning has not been carried out. It can be easy to get caught up in the grandeur of all-conquering product design - the excitement that is generated through innovation is a powerful motivator for a team. However, targeting a complete "finished" product without trialing can increase the risk of failure or at least make it likely that significant change will need to be made to the product post-deployment.

MVP can help mitigate these risks by getting the product to the users as early as possible, basing subsequent decisions on real data. Value from the software is returned quickly; initially in terms of feedback and in later, fuller releases, financial return. Issues (and new ideas) can be discussed openly and resolved before compounding into greater challenges and features that were considered essential during the early days of planning may not be required at all, saving money.

To MVP and Beyond - A Journey to Happy

It can take significant time for a software product to mature; numerous iterations of the feature sets. Taking the time to comprehend this and embrace an iterative development process can help reduce frustration amongst stakeholders where this was not the expectation.

Possibly the leap of faith is to accept that the first few releases will almost undoubtably not make the customer (be it end-user, business owner etc) happy. The main intention here is simply to gather feedback for later releases: -

As a final take-away, it's worth noting that the principles of MVP can work just as well for simpler software projects as they can for large scale roll-outs. A smaller set of requirements does not necessarily mean that all assumptions made at the outset will be correct, no matter how obvious they may seem.

Getting Started with Software Projects

Mon, 03 Feb 2020 17:08:26 GMT

Perhaps it’s the frustrated calls from internal teams, or partners crying out for greater connectivity to data – cases for implementing new software are easy to find. So much so that many projects get no further than a footnote in a meeting, while others fail after years of investment and effort.

So how do you start well and improve chances of success, particularly in organisations where internal knowledge and experience may be limited?

Begin at the End

It’s easy to get up in current challenges, the latest tech trends, project plans and budgetary constraints when really the initial focus should be a simple one; where are we trying to get to?

The answers can (and should) at this point be straightforward, and small enough that they encapsulate the requirement and nothing more.

For example: -

Customers would be better informed if our sales representatives had live data when out on visits.
We would surpass most competitors if it took half the time to process new sales orders.
A stable database would allow teams to focus on more productive activities.
An effective CRM would reduce oversight and increase retention amongst our customer base.

All these indicate challenges but also allude to an end goal. There is no consideration on technology, costs, timescales or the minutia of solution at this point however, simply what is trying to be achieved. Sometimes, summarising a requirement may be difficult in itself; if you are struggling with this aspect then keeping the benefits to the customer in mind is always a good strategy.

The Importance of Good Advisory

Once the overarching requirement is identified you can start to break down the steps required to reach the end-goal. There are of course a lot of unknowns between this point and a working software implementation. The path will vary depending on the nature of the project but one thing that in common is the importance of getting good advice.

This advice may come from internal resource or a trusted external partner, but it is essential to getting a green light and the decision-making process moving forward. Mistakes are almost inevitable where complex software is involved, however critical issues can be mitigated by having experienced people around. They can help both highlight and weigh-up considerations for the project moving forward, which might include: -

Requirement Gathering; breaking down the top-level need into smaller chunks, or "stories" will stand you in good stead. A well considered, user-focused set of requirements aids prioritising, planning and all decision making as the project progresses.
To Buy or to Build ; the market for go-to software solutions is enormous, with many CRM, ERP and database offerings available. Most of these now allow for a degree of customisation but there are also times when building a home-grown solution from scratch is the right way to go.
Choosing Solution Partners ; alongside big players such as Salesforce and Microsoft are a wealth of smaller providers as well as software houses who can help with bespoke implementations. Functionality, security, infrastructure, interface are all factors in this decision.
Technical Unknowns ; breaking the back of difficult technical challenges early is often a great way to go. Spending considerable time realising a deployment only to fall or find delay at the last hurdle is a misstep that can be avoided.
On-Boarding ; it’s surprising how often significant effort will go into a new software project only for the users to be the last consideration. A smooth transition, particularly when replacing an existing system, will help the software have a happy existence from get-go and encourage positivity amongst your teams.
Budgeting ; managing cost and timescale is a skill in itself, particularly when there can be so many unanswered questions. An unrealistic budget might result in a valuable project not getting off the ground or frustration from all involved. Of course, ill-advised spend can also have a negative effect so spend should be targeted throughout. An “MVP” approach can help focus the mind with respect to costs and timescales (see later point) and deliver true value at an early stage.

A single person with deep knowledge of all the possible areas you may need is hard to find but having a stakeholder who is familiar with, or has experience in delivering software implementations is a valuable asset. They can talk openly with other members of the team, help prioritise requirements.

Implementation - The Power of MVP

Once you're ready to get underway, it's is worth considering an MVP approach . MVP means a “Minimum Viable Product”, it’s a clever way of saying the least effort required to deliver something that can be used.

Many software projects fail (or are harder than they should be) due to overreach. Software implementation should be an iterative process. Recognising that the fewer features that are targeted initially will not just result in faster delivery but a better product in the longer term is a hard but valuable lesson to learn.

There are many methods to implement a software project. The skills required will vary based on some of the outputs identified during your initial requirement gathering. For example, DIY software projects require technical teams, designers and an understanding of software approach (Agile, Waterfall) etc. A packaged CRM installation for 10 users is far simpler, but still has necessary steps to success and can also benefit from an MVP installation.

The End has No End

At the outset of this article I suggested how the end is a good place to begin. A bit of a spoiler but it’s worth noting at this point that what you think is the end, is highly unlikely to be the end. In fact, it’s reasonable to state there is no end!

The most important takeaway from this is to plan for ongoing learning and enhancement. This doesn’t mean adding features to your software for necessities sake. It would be prudent to remember that many software projects come about to replace a system that has been poorly over-developed. Rather to ask the right questions, refine and ensure that you continue to get the most possible value.