Getting it right

We recently came across the interesting experience where a person got in touch with us after a gap of over a year. We had a number of discussions during our last engagement, and although the client was happy with the proposal and prototype we had presented, he felt that the pricing was unreasonable, especially considering the low rates easily available in the market.

What made the re engagement so interesting was that the client had completely forgotten about the earlier attempt and had gotten in touch with us as if it was the first time he was discussing with us. He however started off by giving us a description his his journey thus far. Unfortunately, subsequent to our discussion, he had tried to work with two software teams, and ended up burning his fingers both times. In addition, he ended up losing a substantial amount of money and time in the process.

The sad thing is that such experiences are not rare, in the world of software development. Even today more than 50% of all projects fail.  While some projects may be doomed due to factors outside everyone’s control,  surely the percentage of failures is too high for comfort. As a potential customer, how do I go about finding a partner who can increase the odds of my project completing successfully?

Our experience of over 10 years of successful project completions have taught us a few lessons:-

  1. Always choose a software partner who seeks to understand the context of the project, not just the requirements.Good project management involves making prioritization decisions. A good understanding of the context gives the Project Manager the information he needs to make the right prioritization.
  2. Choose a partner who seeks to connect to the core problem you want solved:Software vendors often assume wrongly that the customer is the best person to define the solution. What they don’t understand is that if the customer knew how to solve the problem he would need a software partner in the first place. Software vendors, with their depth and breadth of experience bring a strong technical perspective to the problem, and this can prove vital to defining the solution. In addition, good software partners define and put in place metrics that help you understand exactly how close you are to the solution at any given point of time.
  3. Choose a partner who is willing to walk alongside till you solve the problem:Very rarely will a custom developed solution meet all expectations the first time out. Multiple iterations and corrections are an integral part of any software development life cycle. make sure your software partner is willing to stay with you over the long haul.

Of course, all of this is easier said than done. How exactly does one go about validating that software companies you talk to meet these three essential criteria? Well, you could go about defining an extensive questionnaire, followed by in-depth interviews, research customer references and do an on-site survey yourself. Or you can just write to us at

Solving problems or implementing projects?

In the words of a frustrated software client, it’s very possible for software development firms “do everything that the client asks for, without doing anything that the client needs.” It seems like a contradiction in terms, but those of us who have been in the industry for over a decade will know how easily possible (and even likely) this is.

Conventional project management starts by looking at the requirements of the software solution that needs to be implemented. But business users are not always the best people to define solution features (aka “requirements”) . Successful software projects start by looking at the problem in-depth. What is the problem that needs to be solved? How did the problem reach its current level? What are the consequences if the problem is not resolved? How is the problem currently managed? Who are the key stakeholders?
The solution must address all of these questions. Every stakeholder must see a win in the solution. Unfortunately, many projects fail because this aspect is often ignored. I have seen a number of projects that get developed simply because it was the CEO’s (or some other senior manager’s) idea, and the analyst fails to look at the needs of the other stakeholders. the end result often is that the software gets built and launched, but dies a slow death due to active and passive resistance by the lower level staff who need to use the software.

But good analysis of the problem is not just useful to the client, it also gives the Project manager and the development team a lot of flexibility. All Project Managers in Stylus have, over their careers, seen problem and solutions over a range of industries. By reconnecting back to the problem rather than starting the journey from the solution features, they are able to apply this cross industry experience, and often come up with innovative solutions that reduce development time while simultaneously increasing solution effectiveness. if nothing else, connecting at the problem level gives the Project manager to suggest alternate solutions if the suggested solution is not technically feasible.
If connecting the solution back to the problem has all of these advantages, then why hasn’t been widely practiced? One reason could be that most analysts are grown to where they are after a number of years as programmers and technical leads. One reason why companies prefer this is because analysts with strong technical skills can quickly bring in technical feedback, so that the client does not spend unnecessary time on requirements that cannot be implemented. However, it also has the disadvantage in that the analyst gets into the solution far too early, and doesn’t spend enough time to validate that the problem is actually the right one to be solved.
At Stylus, we have developed our proprietary Analysis and Architecture process called RadicalRooting™. The process ensures that adequate time is spent to understand and anchor solutions around problems and not the other way round. Once the core problem is clearly defined, the RadicalRooting™ process ensures that reports are designed to track not just how well the solution performs, but also how well the problem is finally getting resolved through the solution. If you feel this is something you expect from your software development team, or if you would like to know more about this, contact us, and I will be happy to take any questions or suggestions you may have.

Reports led Software Design

As a business leader, one of the things that mytifies me is how software development teams look at reports as an afterthought during software analysis/ requirement capture. As a result, the reports tend to highlight how the software works and whatever data the system captures, in various permutations and combinations without ever telling whether the problem, for which the software was developed in the first place, was ever solved.

Is it any surprise then, when the CEO looks at his IT manager, and grumbles that IT just doesn’t get the business? Nothwithstanding the advantages of running numerous “Align IT with Business” initiatives” (advantage for the consultants, that is), I’ve always wondered why CIOs / IT Managers don’t start their software architecture/design by first defining reports that clealy show whether the problem is being solved, and to what extent.

In many cases, these metrics were never defined, and it is here that IT can bring in the first “business level” contribution. Once these metrics (and reports) have been defined, then the next step would logically be to measure the current “as is” situation. Again, here too there may be instances where business function has no idea of how the problem is currently being managed, and again, IT can contribute to the business by mapping the exisiting business processes.

As a CEO, this information now allows me to confirm whether an IT intervention is actually needed, what it’s “core business benefits” should be, and what are the absolutely essential features of the software that needs to be developed to solve the problem/ improve the situation. I distinguish “core business benefits” from a more generic ‘cost/ benefit” exercise in that while a Cost / benefit analysis normally looks at an “inside out” picture (what all the software can do versus how much it will cost to build them in) a “core business benefit” gives an “outside in” perspective (what the essentially few things that the software must do well to solve a business problem).

As an Intelligent Business software provider, at Stylus, this is a challenge we have taken on, and our RadicalRootingTM process looks at software requirements backwards, starting from the reports that tell us what problem the software seeks to solve and then allow that insight to define what the software should and should not do. It’s amazing what we’ve learnt through this, but I guess that’s the subject of another blog in the near future. It isn’t an easy ride, but as we see our clients’ businesses succeed, it confirms that it’s a worthwhile one.