(Original creator: michaelrabone)

Once upon a time (otherwise known as when I first worked in analysis) it was possible for the guardians of the purse to call for a set of numbers indicating the cost of procuring a new application.  Much activity would take place, usually lasting months or even years, whilst information on operational, technical and, most importantly, economic feasibility was gathered.  Thereafter estimates were produced and, in due time, formal plans.  With luck, during this process, the users of the proposed application were consulted and a list of all that would be included in the development was drawn up and formally signed off.  At this point the users knew what they thought the application would include; those involved with development knew what they considered was expected of them (even if they were unsure how to produce it) and, most significantly, the guardians of the purse knew exactly how much money had to be set aside for the task. Invariably, even in the best regulated environments, the story then took a turn for the worst: Beset by problems of technical difficulty because so much was untried; hampered by arguments about changes in the business that were not being incorporated into the new application and hamstrung by the need to stay within budgets set before a realistic estimate could be arrived at. 

The experiences of those involved in these epics are stuff of legend.  Everyone knew how awful things could become with disillusioned project teams and users being given out-of-date and irrelevant application .  Everyone was unhappy except, perhaps, the money managers.  They had their estimates, they could argue for economies, they could set aside the correct amount of money, as they saw it, and they could berate the project teams whenever any limit was breached. Who were these guardians of the purse?  They ranged from true financial staffs right down to everyday line managers.  All these individuals had a vested interest in ensuring that they could forecast, plan and account for the activities associated with the project. What about the others involved?  Yes, the users want to know how long the application would take to develop and the project teams desire the satisfaction of finishing a phase or even a project by the due date.  But such matters were unlikely to be the major concerns of these groups.  Users really want systems that will be useful; that will assist them in their day to day work; will make their life easier or more profitable or more satisfying.  Project teams want to produce beautifully crafted technical solutions, utilising the most up to date technology and moving their career resume on to new heights.

When a group has a single or unified aim it is, obviously, likely to be more easily achieved than if objectives differ or are, at their worst, in direct competition or confrontation.  To provide an environment where the aspirations of all groups are met really is likely to be a fairy tale. What can be done to allow applications to be developed in an atmosphere which is more harmonious than haunting?  The users must consider themselves the owners of the application. If the development is seen as an “IT system” it is likely seen as being the property of the “IT Department”.  Projects are, by their very nature, transitory.  Time, effort and money have to be expended; business managers have to be absolutely clear about the importance of including their resources in the development as well as those of the IT Department or Project Team.  It is recognised that there is little “fat” in any job.  Most workers already have a full day without the introduction of a project team who will take up time, space and equipment for even a limited period.  However, if the users don’t own the application they are unlikely to get what they require and the only useful training for developers will be a course in “Fortune Telling”. Modern development techniques need not and indeed, in my opinion, should not be an unstructured exercise.  But the use of discovery and prototyping methodologies mean it is very difficult to produce even good estimates of time and cost upfront.  Using methodologies like Agile, third-party fixed price contracts will either have to contain enough contingency to make cost-benefit unrealistic or present such a risk to the developers as to be not worth the effort.  Some people say that that trust must be engendered.  Trust between buyer and seller?  In a multi-million dollar system development?  Does this make discovery and prototyping suitable only for in-house projects?  If it does, then the sad fact is that the tools, techniques and technology will be wasted and users will be the biggest losers.


  1. Hi Dave. **** However, if the users don’t own the application they are unlikely to get what they require and the only useful training for developers will be a course in “Fortune Telling” **** I like this sentence in context with "once upon a time": Fairy Tales and Fortune Telling ... Shouldn't the users own their tools as well ?
  2. But what do you do when the users are not trained/competent/interested in designing or owning  a system? A large part of my analysis work consists of both working out what the user is actually asking for and then what they have not thought about when they asked for it. I/we generally get where they want to be, but it usually takes a couple of iterations of prototyping etc, when they start telling you about use-cases they "didn't think of" until now etc. I agree that users should be invested in getting what they want out of a system, but that's not necessarily "owning" it...
  3. Hi Iain, this matches my experiences. I saw a lot of customers literally taking down notes from one screen only to type it into the next screen; they were pretty surprised when I suggested that we (the developers) can populate the fields with these values as a default for them. The other one was a sort for a multi occurence screen which was in the application, but the users were not aware of this feature. They struggled with their list of customers which came in custid sequence while they need it sorted by ZIP-code.
  4. Hi Iain and Uli, thank you for your comments.  3rd party and Value Added Resellers are in a difficult position when it comes to ownership of applications: Their customers, while working in the same broad area, may well have diverse objectives and requirements.  Those that produce bespoke variations of their applications perhaps get closer to the aim of direct customer involvement but still, I believe, have to rely on their own subject matter experts (like you Iain) as much as the end users.  In an in-house development things should be easier; end users more closely grouped in aim and objectives.  However, my point is that those concerned almost entirely with Finance have too much sway in all these developments.  Whilst they have the interests of the business at heart, project teams suggesting that they can't give firm estimates of time and expense before producing prototypes are all too often seen as failing to control their costs instead of working hard to discover the best possible solutions. Your experiences are all too common.  I know that when you want to get a Director of Operations involved in building a prototype, you are often told they are far too busy and offered alternatives such as those in clerical positions; whilst their knowledge of the system may well be as good if not better than some executives, it often means that decisions have to be referred 'up the chain', providing inevitable delays and possible mis-communication: The delays that push up time and cost.  Even after 25 years of 'RAD', some organisations still see systems as being owned solely by the IT department or the reseller and those concerned with Finance able to heap the responsibility on their unfortunate heads. I firmly believe in the benefits of prototyping and the very significant advantages Uniface can offer in this realm.  But the rise in power of the financial controllers and growth in "short term" reporting, ironically made much easier by IT, often means that the long term benefits of discovering the right system are lost in the effort to satisfy the accountants.
  5. Hi Dave, yes, it's nearly impossible to get permission for a refactoring from the "money" side. And the reporting periods which once was years have tunred into a quarter makes it even harder to start something like "Building Blocks". When I gave a presentation a couple of years ago about boosting IDF by adding code snippets support, one reply was something like "my developers may work an hour longer, but they are used to overtime already".
  6. Hi Uli, You are absolutely right.  In some places reporting is now monthly.     The problem is that reaction to short term figures often damages longer term goals.
  7. Maybe that's why there are not enough babies in Germany: they take 9 months to produce.
  8. There are things that companies can do to improve this situation. And they (as usual) involve money and who controls it.

    As much as possible should NOT be done through the IT budget.

    In my ideal picture everybody within an organization should be trained to spot opportunities and possibilities for improvement. Coming forward with them should be rewarded and suggestions should be taken extremely seriously. Anything with a good return on investment should be executed. It does not matter whether the suggestion is about reducing the cost for office supplies, increasing the income of the company by a different way of selling the product, or improving the effectiveness of IT systems.

    There does not need to be an IT development budget or even an IT strategy. Anything with a return on investment within a certain period, say a year, should be simply be executed.

    In this picture there are no budgets, only investments. It will create a way of thinking where IT is not seen as a cost center but as a way of making more profit.

    Some things do need to come from a budget

    Only things with a much longer return on investment, like converting to a new hardware platform require some sort of budget. Projects like these are usually not very interesting for improving business processes and such, but are still needed for long term stability. It is not much different from replacing the fire extinguishers in your building on time.

    There is money waiting to be used

    When a company does an investment it usually writes off that investment in a couple of years. Except when it comes to software. The bookkeepers probably will duly write of the investment in the books, but for the IT department and the management it is usually a big surprise that an IT system needs replacing or a major overhaul. The money to do it should have been reserved as the old system is slowly being written off, but sadly it not always is....