News Stay informed about the latest enterprise technology news and product updates.

How is compliance hurt if software development projects are 'doomed'?

You’ve seen it before, no doubt: Your organization develops a software project, with both business executives and IT careful when outlining its objectives, developing a plan and making sure it adheres to compliance regulations. Then, after countless hours of work, the project falls apart.

Trying to answer why this happens so often was the goal of a recent Geneca study, “Doomed from the Start? Why a Majority of business and IT Teams Anticipate Their Software Development Projects Will Fail.” The study examined why IT teams struggle to meet business expectations for their projects, and asked participants questions on topics such as requirements, accountability and measuring project success. A high number of respondents showed a lack of confidence in their projects’ success, with 75% of respondents saying that their projects are either always or usually “doomed right from the start.”

Geneca cited several problems causing the lack of confidence in the projects’ overall success. Key study findings include:

  • 80% of respondents said they spend at least half their time on rework.
  • 78% said the business is usually or always out of sync with project requirements and business stakeholders need to be more involved and engaged in the requirements process.
  • 55% said that the business objectives of their projects are clear to them.
  • 23% stated that they are always in agreement when a project is truly done.

Another interesting finding was that 76% of IT respondents and 72% of business respondents agree that IT is a “trusted partner and critical to the company’s success.” However, IT people assume that their business colleagues believe that “IT doesn’t build what the business asks for” (42%), “projects are always over budget and take too long” (33%), and that “IT needs to provide more warning when a project is going to be over budget or late” (28%).

A Geneca report accompanying the survey stated that the responses from IT professionals and their business counterparts were fairly similar. In addition, each side had many of the same issues and concerns with regard to their projects.

“The perception is that challenges start at the beginning of a project and reflect difficulty in defining project success,” according to the Geneca report. “This carries forward to IT and has impact throughout the rest of the project.”

Geneca representatives advised professionals to examine their processes and try to facilitate the following to alleviate obstacles outlined in the study:

  • Communication of clear business objectives.
  • Measurement of project results against business objectives.
  • Ownership of the project goals vs. design of the solution.
  • Collaboration between the business and IT to drive alignment.
  • A common vision across every part of the organization involved.

All sound advice. As the report notes, the project management problems outlined above are interconnected and compound each other when left unchecked. And what about when a project is designed to create a compliance solution or related to meeting compliance regulations? With the number of compliance regulations out there, and many more likely to come, a project’s success could make or break your company’s adherence to the rules. As a result, getting it right the first time is more important than ever.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

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!
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.
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: [ULIST] [ELEMENT]Create user input screen based on database fields with standard CRUD behaviors.[/ELEMENT] [/ULIST] 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.