Main Points

History is Now

This step of development comes before anything else, technically before the entire SDLC. However, you can't start the SDLC without it, because you can't start a project without having one; hence Full Software Development Life Cycle (FSDLC). It goes by many names. Project identification, business process analysis, systems analysis, business analysis, process analysis, etc. It ultimately boils down to this. Technical projects evolve from people. Technical projects are determined by what are usually anything but technical reasons. Deciding to take on a project is about desire and insight and the idea that something could be made to work better, faster, cheaper, more efficiently, and / or with less work. As such, before you can sit down to the technical work of building an application, some very non-technical work has to happen first.

From this description, it should be obvious that we're not even dealing with a specifically software-related issue; project development (as well as requirements) are much more fundamental steps in problem solving. As such, this part of the SDLC is applicable to Any situation where a problem needs to be solved.

Process Analysis

The universal first step in problem solving is the process of determining what you should work on. I find the term Process Analysis to be most accurate because you start by analyzing your current processes and procedures to identify flaws and opportunities. For many smaller projects, this step is literally an unconscious or serendipitous prelude to the SDLC; you identify a piece of code or a gap in a process and say "Ah! We need to do X." At this point, of course, you're actually already finished with the analysis that we're talking about; I find this amusing. It means that on many projects, the problem identification is only formally recognized when it's already over. :)

Nevertheless, on larger projects and in most technology or IT departments, analysts are a specific position on the team with the task of locating needs, analyzing current processes, and identifying projects which can meet those needs and streamline those processes. In the grand scheme of software development, this is one of the most creative, artistic jobs, and yet it requires an excellent grasp of technical concepts and in most cases requires someone with a lot of experience throughout the entire SDLC.

Process Analysis may begin with project identification, but it rapidly begins to deal with issues like "Is this a feasible project?" "Will this project provide a return on our investment?" and "How important is this project compared to the other items on our project list?" Naturally, these questions can only be answered by someone with a fair amount of experience completing and managing projects. An analyst needs to mentally predict how the entire project will go in order to assess its feasibility, potential, and difficulty.

Gap Analysis

Process analysis is about studying processes and procedures. It's about taking a look at what some program, some person, or something is doing. Gap analysis is an entirely different breed of animal. If process analysis is about studying A, the set of all the processes and procedures that you're currently using, gap analysis is about studying the complement of A, the set of all the processes and procedures that you're not using. The purpose of gap analysis is to think outside the box and imagine all the ideas that you could be doing; therefore one of the few practical ways of wrapping your mind around the opportunities available via gap analysis is to study your current processes.

While gap analysis is less about research and more about dreaming, that doesn't mean that you don't start in the same place. Systematically examining the processes used to solve certain problems is an excellent way to learn how to streamline those processes. When it comes to gap analysis it's also one of the best procedures to use to get to know the system. You're just approaching it with a different purpose.

That said, there is an excellent way to cheat. Studying how other people are approaching this problem will sometimes turn up revolutionary ways of doing things that your current processes have missed. So too, you can look further afield to see how other people are approaching other problems to see if a solution applied in a different context might have some application for a problem that you are trying to solve. Frequently gap analysis is just about applying an old idea to a field where it has never been used before. There are frequently good reasons that a particular solution has not been used, but occasionally there are solutions that fit which no one had ever seen before.

In short, it is not only useful to study your own problem, but the field of problem solving in general. Quality gap analysis systematically sets aside time to consider each branch, general problem solving and the specific problem under consideration. As you examine projects that are more and more different from your current problem, it is true that you're less and less likely to find an immediate application for what you learn. However, anything you find that's applicable is more and more likely to be important. This is the stuff of which revolutions are made. And it's exactly this kind of process which is at the heart of gap analysis.

Project Evaluation

Once you have identified your potential projects, you need to work out how to cope with them. Resources are necessarily limited and you cannot do everything at the same time. Your project list is the collection of projects which you've determined your development team could be working on. Now comes the process of evaluation. This is where there is no alternative to experience: the experience of building applications, of testing them with end users and stakeholders, of understanding the process of problem solving. The earlier phases of project identification can to a certain extent, be performed by any reasonably intelligent person. This is where it becomes important to have experience building projects.

During project evaluation, you determine what the value of the project will be, estimate the resources needed to accomplish it, and predict exactly how the project will be completed. There are no "answers" for this phase, you have to draw on any experience and imagination. You have to compare this project to similar projects you have worked on previously, and imagine how this one will proceed. Once you've had a chance to evaluate the project, the first question is whether the project is worthwhile. If the resources you have to expend on a project are greater than any value you can ever get out of it, you can cross it off your list. If you do not have the resources necessary to pursue a project then it doesn't matter how important it is; if you can't do it, there's no point considering it and you can cross it off your list.

Identifying possible projects is probably the primary job of an analyst; after all, it is their job to keep the development team busy. However, the most "useful" work that an analyst can ever perform is to eliminate projects which do not have true potential. 3rd Party Software, while seductive, frequently falls into this category. Organizations frequently define a need, determine they want to pay the minimum amount, and go looking for the "best" available off-the-shelf solution. If the "best" does not meet your spec, then it is an anti-solution at any price; yet many businesses not only buy 3rd party software that doesn't meet their specifications, but frequently purchase software after shockingly cursory inspections. In short, most companies have little if any idea whether 3rd party software they have purchased meets their spec or not.

On the contrary, approaching 3rd party software requires the same care and attention that your custom development demands during project evaluation. Approached correctly, 3rd party software can absolutely be a useful and cost effective choice for an organization. But if it is treated differently than any other project, it easily becomes an anti-solution that institutionalizes the the acceptance of failure. Don't make that mistake.

Prioritization

For those projects that remain, it is time to put your money where your mouth is. Having evaluated your projects, you have to decide what order they should be implemented. New projects must find a place in the order of the existing project list. The return on investment may be the most important measure to consider, but there are certainly others. The resources required to complete a project is also a key factor. Organizations have many times pursued projects in hopes of big returns and expended vast amounts of resources only to discover that once the project was complete, the returns could not even cover the original cost of investment. Not that this is an inherently bad thing; project evaluation is an art not a science. On one hand, an organization should never threaten its existence by pursuing a project whose failure would destroy it; however, an organization that never experiences failure is too conservative. Don't miss out on important growth opportunities. Try new things, be assertive; especially if you manage your risk wisely, there's no reason not to go after big game.

Also, the interplay of different projects should be considered. If one large project is clearly the most important priority, it may not be the best choice for the top spot. If part of the project architecture can be implemented by completing a small project, then it's foolish to stall the small project for the large one. You could be building your way towards the large project and checking off secondary priorities at the same time. The amount of "unrelated" work necessary to complete the secondary project is probably the key factor in whether this kind of overlapping project is really efficient. If not, the reverse project order will still provide efficiencies; the large project will put in place key elements of architecture for the secondary project and make it smaller and easier to implement. Either way, this type of efficiency allows you to conserve time, your most important resource and yet one which is often managed poorly.

However, the appropriate identification of secondary projects is key. It not only allows you to build additional functionality on the way to completing the primary project, but usually improves the quality of the primary project as well. Managing change and growth in your application is one of the most critical and important activities which you can accomplish; in practice, it is notoriously difficult to achieve. Building secondary projects on the way to your larger project effectively "front loads" change management. This ensures that changes are beautifully customized to your needs – basically – even before you begin large, mission-critical projects. Depending on your circumstances, it is sometimes a good idea to build your way into a large project if only for this benefit. However, when in doubt, err on the side of getting the big stuff done; it is far too easy to become distracted with small projects.

Two Project Lists

What I find most effective is to create two project lists. My first project list is a raw evaluation of project value. You can determine for yourself if you want this to be the strict ROI or an evaluation of value (return vs. investment). I absolutely recommend using value, but whatever you choose be sure to explicitly state which you have chosen at the top of the list. It is too easy to simply think of your list as "project importance" which is too fuzzy and emotional a concept to be useful in professional project development.

My second list is rearranged to identify the actual order in which to pursue projects. This is put in project order and identifies the name of the project, its value from the first list, and reasons (if any) why it was moved ahead of projects which it was previously behind on the first list. This is a useful way to stay focused on and documenting project value in list one, while providing the flexibility to shuffle projects around into the most sensible arrangement for actual development on list two. Perhaps just as importantly, list two requires you to justify any reasons for changing the order of projects, which is an important habit to establish. Flexibility is good, but you shouldn't shuffle project priorities without a good reason. If you are like me, and follow the best practice of iterative development, you define your iterations while building the second list.

At the completion of project development, you now have a list of projects on which to work. There's no need to ask what ifs or whys, you can now put the blinders on, grab the project on top of the list and dive into the SDLC. Note that the first step is requirements development, a key step in any form of problem solving. But we have at least moved into the traditionally recognized realm of the SDLC.