We know you've heard all this before. So when we say we do feasibility studies, you'd be forgiven for asking 'so what's new?'
The basic tenets of software project management are ingrained in the minds of everyone even remotely involved in it: "you do a feasibility study, then you embark on a requirements phase (with your full involvement), then we build your software to your exact requirements and test it rigorously to ultimately deliver it without any defects". Sound familiar?
So if it were that simple, why isn't everyone doing it? They all say they do, after all.
Estimation, that's why.
Actually, a lack of knowledge, a paucity of past-project metric data and a too-eager desire to get you to sign up are also factors, but let's focus on estimation for now.
You want to know how long it will take and how much it will cost. A developer wants to give you the lowest figures to get you to say yes… see the dichotomy?
Add to that the fact that low figures and off-the-cuff guesses tend to get remembered, taken as gospel and incorporated into cashflows and cost-benefit projections, then even the slightest addition is felt as a huge increase.
So get the initial estimate wrong and the whole project is doomed to failure.
Get Symbiosys Systems in to do it, however, and there are no surprises - except good ones.
We don't just give you a huge estimate to cover ourselves. Neither do we give you an unrealistically low one to win your business.
We tell you the truth.
We investigate your business IT requirements and tell you exactly what it will take to meet them, either with packaged software, developed software or some combination. We've even been known to say you don't need anything.
But the main thing is that if you call us in, you know that what we deliver to you in our written feasibility study is everything that you need and nothing that you don't.
If you haven't had any software developed for you before, you might think that it's the pinnacle of business IT customisation. You'll get a system that fits perfectly into your business, streamlines your processes and all the users will love it.
If you have had software developed for you, you're probably laughing out loud by now. Unless the memory is too painful.
The reality is usually that besides being delivered late and defect-ridden, the software never comes with any usable documentation in any format, so the users haven't a clue how to use it. This means they'll hate it and won't use it properly and so it will have even more problems. Documentation is historically left until last and, as the programmers inevitably run out of time, it gets left out and never updated.
Our project management methodology, Insigniter, turns that practise on its head. We write the user manual as we develop the system requirements - before any software is created. In fact, the requirements document is the user manual and all technical specifics are included in addenda, which can easily be deleted from the final user copy.
By developing the requirements document as a user manual, in a 'how to' terminology, with full-colour screenshots of all interfaces, we guarantee that non-technical users can fully understand the intended system and so can see where it will work and where it won't.
It also means we have to create a prototype system to produce those many screenshots, so as developers we see problems before they become real issues.
Finally, when it comes to delivery, the users have seen and reviewed the manual so many times that they need only the most basic of training to use the system fully. Then they really do love it.
But a word of caution - anybody can say they do this, but we have been doing it for years. Always ask for examples and proof before committing to requirements development work.
One more thing… why do we call it requirements development and not requirements analysis or requirements gathering as everyone else does? Because software system requirements need just as much development as the final software. Requirements aren't there to be picked up like apples in an orchard, they need to be grown and harvested from the minds of the users and managers who are used to doing their work but aren't used to designing systems.
Staged delivery.
No matter how you dress up other ways of delivering software, nothing succeeds like the Staged Delivery model. Whether the development company is highly process-oriented or totally chaotic, staged delivery offers the best guarantee of an over-all successful project.
We recognised this when we originally designed our methodology way back in 1998 and while we have continued to tune and improve our methodology ever since, we've stayed with the staged delivery because of this one simple fact: breaking a large, potentially unsolvable problem into a number of smaller, connected, solvable problems is how almost all scientific progress has been made since we've had minds to think with.
It also makes the developers and managers focus on quality, multiple times during the construction phase of the project. Leave the delivery to a single date at the end of a long construction phase and you'll get panic development as time runs out, leading to poor quality delivered software. But if you plan to make multiple milestone deliveries, then each phase gets delivered with fewer defects, thus leading to a final defect-free delivery.
Also, if a given stage doesn't meet the requirements, you don't pay. So you don't waste time or money.