Enterprise Software Development: 11 Tips to Help Avoid a Mess on Your Hands

There Are Many Impactful Subtleties CIOs and Other High-Ranking Corporate Officers Should Be Aware of When Looking to Develop Enterprise Software for Their Companies

---

It may be no ground-breaking news, but roughly half of enterprise-grade software development projects turn belly up when first released. They either then have to be rescued by their owners (certainly, by throwing tons of good money after bad), or just get abandoned to their fate.

Numerous headlines having been made and whopping losses (sometimes hundreds of millions of dollars) incurred by iconic market players in a bunch of industries, we seem to be no closer to a solution than we were, say, 10 years ago. Why?

In our view, there are just too many devils in the details on both the technical and management levels of which even quite experienced enterprise software providers are not yet aware. Many of the things that seem like no big deal, but are, potentially, able to derail a project have to be learned empirically. These things are not mentioned as part of any formalized domain-specific knowledge.

To complicate matters even further, a lot of the time these hazards have to be dealt with collectively by many different project stakeholders. Some of these stakeholders represent the client.

In this article, we’ll share with you several such empirical insights of the great many we’ve picked up while building enterprise-grade software. If you are looking to develop an enterprise application, these tips may help you keep better tabs on your software development contractor.

Big-Time IT SOLUTIONS to BIG-League ENTERPRISE CHALLENGES

Development-Related Tips

1. First and foremost, most enterprise software development projects usually represent wide-ranging development efforts that involve a number of experts. Each of these experts has their own coding habits and their own idea about the way code should look like. After a while, these often conflicting views and habits result in a coding mess that becomes difficult (if not completely impossible) to manage or straighten out. The quality of the code prevents newcomers from getting a handle on the project specifics within a reasonable space of time.

Because of this, you should never embark on any enterprise software development project without introducing a set of detailed and well-thought-out development guidelines. These guidelines must stipulate the rules that will allow you to ensure the uniformity of all the inputs, provided by the different project contributors. Notably, the above rules must detail the requirements for the code to be written, i.e. the use of blanks, tabs, case styles, naming conventions, etc. Make sure that all those, involved in implementing the project, know and strictly follow your development guidelines.

2. Similar to Point 1, quite often the several development teams, engaged implementing an enterprise software development project have varying ideas about what can be considered as “done” or a properly completed assignment. This entails frequent misunderstandings, longer turnaround times, and, sometimes, even, attempts at blame shifting.

   That is why, prior to starting any enterprise software development effort, one should compose, discuss in sufficient depth with all the development teams, and formally introduce a set of “considered as done” criteria to be universally upheld by all of the teams involved. For example, such criteria can include:

   • Coded

   • Compliant with the project-related guidelines.

   • Meets the project-specific acceptance criteria.

   • Committed to a Team branch.

   • Compilable

   • Duly documented

   • Unit Test coverage is no less than 80%.

3. It is imprudent to start an enterprise software development project without defining the areas of responsibility and making corresponding personnel appointments.

   With Agile enterprise software projects, a good rapport between the different development teams is central to a project’s success. This is best achieved with the help of written working agreements between these teams, adopted project-wide.

   For instance, such a written working agreement can stipulate the following rules:

   • Any code is to be written solely in accordance with the project-specific development guidelines.

   • For Sprint-related work, Team branches are to be used.

   • Only those features that are in compliance with the adopted “considered as done” definition are to be committed to the common development branch.

   • Nothing can be committed to a red build (or a build that has failed testing and, thus, is not compilable for some reason).

   • No code that has not undergone a code review can be committed.

   • The Product Owner is to be constantly available to answer questions, posed by the team members.

   • Nobody can ever be late for a meeting.

   • Nobody can come to a meeting unprepared.

   The above rules must be supported/promoted by the PM.

4. It is imperative that all project tasks are track-recorded regardless of their size. Failing this, you may wind up with a massive amount of poorly manageable code, dealing with which will be irksome and extremely time-consuming. Your developers will have to turn themselves into full-time investigators every time they come across an obscure spot in the code. Again, this spells a real pandemonium for those, joining the project at a later stage.

   From our experience, you can enhance your code base’s readability and ease of use immensely by integrating Git and Jira, as well as by using the integration for source control purposes. It will become possible to immediately view history for any of the code changes (in plain talk, when and why a change was made, who made it, and what exactly was done). In any event, it is an absolute must that one follow the Agile paradigm: "Plan what you do, and do what you plan."

Project Management-Related Tips

5. Try to determine if there is a need to make Stakeholder Management part of your Project Management process. Once unidentified at the beginning and overlooked later, this need becomes an insidious scourge that can, in due time, affect the project negatively on a much larger scale than a mere technical issue.

   So, just in short, what is Stakeholder Management, and why is it of so much importance?

   Stakeholder Management is the process of identifying any existing pockets of resistance, created by those of an organization's employees, whose interests are opposed to the project-empowered change.

   Few executives want to believe there can be some undercurrents in their companies that are at variance with whatever is said at high-ranking meetings and festive corporate parties. Alas, this happens all the time. Most often, this happens when the changes that are likely to affect the interests of an individual employee or a specific group of employees begin to loom large and send jitters across the organization. In this case, some of those concerned fail to see any advantages the forthcoming innovations can create for them personally. Simultaneously, they set too great a store upon the possible disadvantages and risks they may be exposed to.

   You simply cannot afford not to identify such employee groups or employees in order to alleviate or dispel their fears by explaining to them how your project will benefit them. In the absence of this, the fallout can include a severe lack of cooperation, deliberate protraction and missed deadlines, and, eventually, a stalemated project it will cost you a mint to bring back on track.