Hello, GonzoBankers. Today, I thought we would take a stroll along the path of software development. Now, you may be asking yourself: why in the world would we want to do that!?!?
To that I respond…
Very good question!
It is a path that is fraught with peril and risk. Littered along the way are carcasses of unfinished projects, bottomless money pits, and the haunting specters of unfulfilled promises.
In spite of all this, the decision to embark upon the path of software development within the organization is made quite often. The decision takes on many different forms, but at some point, there is an overriding belief that “We can do it better ourselves!” It all starts out innocently enough, a simple integration of disparate systems, creation of the company intranet, or a quick email automation project, but quicker than you can imagine, the trouble begins.
Now this is not meant to be a slam on fellow GonzoBanker Michael Croal’s article about those little development band-aids (see “When is a Band-Aid Good Enough”) – those are vital to an organization’s health and well being. But sooner than later, a time arrives when the realization dawns that an ad hoc approach to development is just not going to fit with the bank’s explosive growth plans.
What I do intend to discuss are some of the key pieces that need to be in place to successfully navigate the dangers along the way by implementing a solid software development lifecycle plan – SDLC for short.
aka Project Proposal, Work Order, Statement of Work, Request for <fill in your favorite term>
The most difficult step in any project is often the first. When a business unit submits a request for work, the process of understanding what is really needed begins. A complete understanding of the business and the problems being faced by the business unit are the foundation of the project. If the need is not articulated well, then disaster strikes. Once an understanding has been developed, the available solutions for the problem at hand can be analyzed, the best course of action planned and, most importantly, the benefit to the business articulated. The analysis will document the initial scope of the project, the resources needed to complete the project, and the project’s schedule – the classic drivers to virtually any project.
System Design or Architecture
A preliminary system design must be performed prior to creating a project plan and effort estimate. Depending upon the size of the project, the preliminary system design can take a team of highly experienced project leads anywhere from several hours to several years. OK, probably months, but it seams like years. This exercise compares options against internal architectural standards and creates a high level view of how all the components of the system will work together. This is an iterative process, so expect the results of this activity to change drastically as knowledge of the project increases, but don’t skip it, otherwise the project plan and effort estimate are just wild guesses. More on that in a minute…
It is well known that a major cause for the failure of development projects is lack of planning. Oftentimes this translates to “…We had a project plan at the start, but things got too hectic to maintain it.” Without proper maintenance of the plan, it will be impossible to determine if the project milestones are being met and, if not, what needs to be done to correct the situation. As many will argue, the preliminary plan is nothing more than a best guess. But the operative word here is not guess – it is best. The assumption is that quite a bit of work has been done with regards to the preliminary system design, and the team has a pretty good idea of how the system will look.
Creation of the plan is always a bit fun. If you start with a completion date and work backwards, this may lead to unrealistic resource requirements. Conversely, planning the project from the start date forward based upon available resources may lead to an unrealistic completion date. If either of these situations exist, break out the Rock ’em Sock ’em Robots because there’s gonna be some haggling over features, resources and schedule.
The responsibility matrix is used to document the roles needed to perform the project, define the responsibilities for each of the roles, group the roles into functional teams, and assign the teams/roles to project tasks. The matrix can be a document that complements the project plan, but in many cases, it is actually just integrated into the actual plan. It is amazing how much smoother problem resolution will be if this matrix exists.
Change Management Specification
Controlling change and expectations for a project are critical factors for determining success. Even if a project is completed on time and within budget, it could be viewed as a failure by the project sponsor if requested changes have not been made. Now, why am I bringing this up before even listing any specification or development activities? Because: change happens. It starts early, and you had better have the right process and tools to manage it!
Tool Selection Specification
The selection of the appropriate tools to be used for development of software projects is critical to the success of each project. Productivity will hinge upon the team’s familiarity with the set of tools to be used. Make sure preferred tools have been identified for each particular function within the SDLC:
It is helpful to include a brief summary of each tool’s capabilities and a justification for why the preferred tool was considered best for the organization. This last step can be of particular importance as the project progresses. As the responsibilities of the project transfer from one person to the next, it is a natural inclination to question why some particular tool or method was chosen – especially if things are not going as well as planned. If the reasoning behind a particular choice is known, then an informed decision can be made as to whether the initial plan should be adhered to, or if changes are in order.
Project Coding Standards and Conventions
Unless the project will involve only a few people who will be working closely together at all times, it is essential to put together a coding convention specification that will serve as the developer’s handbook. This does not have to be difficult as there are many examples available on the Web to get you started. There are many benefits to be realized from the implementation of coding conventions. A few are as follows:
Keep in mind that the conventions should allow for consistent development practices but should not restrict the developer from providing the functionality requested by the user, or the use of new features that may make a program easier to use.
We have covered many of the critical supporting processes, and it is here that I will stop for now. Our beloved GonzoEditor has constantly warned me about the nod factor inherent in my technical articles, and I fear that I may have passed the point of no return.
Those GonzoBankers who have been personally mired in the process of SDLC creation are probably thinking that I’ve only hit on 10% of all the items that are really necessary to create a well functioning SDLC – heck, you’ve probably seen the project planning function alone fill binders with templates and forms! I do agree that this is kind of like that little piece of ice the Titanic hit. The deeper you go, the more there is to see.
A key takeaway from this discussion should be that there is significant effort and discipline required to create a comprehensive SDLC. If you can’t wait to learn more on the topic, then I can safely say that software development, and the competitive advantages that it can offer, may be for you. On the other hand, if reading this makes you want to run to your nearest vendor and hand over all the tools that are even remotely related to development, then you may want to consider beefing up those vendor relationships, and handing over the reins.
Either way, make sure that the roadmap we call the Strategic Technology Plan reflects the path best suited. Is yours ready?
For more than a decade, the professionals at Cornerstone Advisors have been helping financial institutions assess the impact of changes in the marketplace to determine how they can best be positioned to successfully and competitively meet industry challenges.
Cornerstone offers expert guidance in a wide variety of areas, including:
Cornerstone Advisors. Where strategy meets execution.