How is compliance hurt if software development projects are ‘doomed’?

BobP60  |   Mar 29 2011   4:44PM GMT

Many companies and people are stuck in the 70’s and 80’s methods of software development. I have seen time and time again that people at these companies forget about one of the absolute most basic concepts and that is creating a requirements document. This ALWAYS involves talks - several - with the “end user” of the product but also with others who will utilize it in various ways.

Once requirements have been SIGNED OFF, then comes SPECIFICATIONS. The specs MUST be tied directly to either real or derived requirements. And keep going with this model. Anytime a milestone is pass (e.g. requirements signed off), it MUST BE UNDERSTOOD that there WILL BE AN ADDITIONAL cost associated with revisiting those requirements later and, the later you do it the MORE the cost!

I am willing to be that less than 50% of all software projects can point to a REQUIREMENTS document! They may have some “spec” that someone tried to write to satisfy both end but this is NOT the way it should be done!

Rdefazio12  |   Mar 29 2011   5:19PM GMT

My experience with software projects tells me that three of the most important root causes of project failures are end users’ unfamiliarity with thinking in a creative way about how processes could or should work in a perfect world, IT’s fundamental inability or unwillingness to acknowledge the validity of user input into the design process, and IT’s inability or unwillingness to create software that deviates from the menu/form programming paradigm. Let me briefly explain each.

End users in most companies are hired and groomed based on their likelihood of being good so-called “worker bees.” They are asked to accommodate themselves to existing processes so that things can flow smoothly. This plainly does not encourage free thinking and pondering “what if” scenarios. Conformity is the rule of the day, so when it comes time for end users to be consulted with respect to how a process should redesigned and to provide lots of detail about how that redesigned process should be implemented to make it truly useful, the input is usually disappointing. The lack of clarity of thought and specific, analytic input that takes into consideration workflow and usability features forces IT to come up with solutions that implement what are usually only general guidelines.

IT’s most common response to user input, largely because of its lack of specificity with respect to implementation, it to regard user input as being tantamount to being a wish list and not necessarily a list of requirements. It is almost like a parent listening to a child’s Christmas list and then proceeding to get something close enough to pass for what was inarticulately expressed by the child. This, of course, leads to a continuous loop of proposed beta versions of a project becoming alpha versions with heavy modification requests. It is partially this lack of specific, well thought out user input and a somewhat condescending view of IT personnel that contributes to longer than expected development cycles.

IT expresses its solutions in ways that are too frequently unimaginative and if I might say so as an IT employee, clueless with regard to what it is like to work in the end users’ roles in the company. For instance, let’s say an end user who accepts orders from customers and who is expected to enter the orders, to check for anticipated delivery status, and to process payments described their work to an IT consultant. The consultant would likely listen for process descriptions and would walk away from the meeting with fairly clear impressions of the separate tasks. He would create specifications that require the creation of a menu of options and a series of screens to accept and to display data based on the options selected. Technically speaking, the end result might conform to the description of tasks that the end user described. What the consultant likely would not assimilate from the discussion is the sense of urgency and stress under which the end user works. Menu driven applications may tend to complicate issues, not clarify them, when the end user really wants software that flows with the work. A remedy that I have proposed often and which has never yet been implemented is to have the IT worker spend one entire day doing the work of the end user under the end user’s supervision in order to give the employee the “feel” of what it is to walk a mile in the shoes of the end user. I think that if such were a pre-requisite to any work being done on a new project, it could significantly shorten the development cycle.

Rdefazio12  |   Mar 29 2011   5:29PM GMT

One more observation about specifications. One of the chief contributory factors to project failure is the practice of “eyeballing” a specification item. The item might be:

• Create user input screen based on database fields with standard CRUD behaviors.

The fact is that usability is often not a function of matching up database fields which contain data primitives with what the user expects from a ease of use perspective.

An example would be requiring the user to memorize codes instead of producing a dropdown list. Creation of the dropdown list might be conceptually easy to visualize, but creating it so that it draws from the right database resource, translates codes to human readable and meaningful values, allowing for multiple selection, and parsing the selections to conform to business rules is not necessarily as easy to visualize. In effect, the one sentence description might be assumed to take 15 minutes, but if all the details were created as separate bullet points in the list of specifications, the time allocation would be significantly longer, and the behavior of the screen control would be more easily understood by the end user at the design stage, thus allowing for more specific input from those who would actually use the software product.

Simply put, no specification should be capable of being broken down further into constituent tasks. If it can, the specification has not been defined carefully enough.