As I gain experience I tend to forget that it is precisely that experience which I rely on for "knowledge" rather than the theoretical teachings of long ago. I have a Masters of Science in Computer Science so you can bet I took a course or two on Software Lifecycles; certainly by the time I left school I was well aware of the topic -- but it was years later before I understood it.
I was taught that "proper software development has a lifecycle", roughly:
- Requirements gathering
- Design
- Build
- QA
- Deploy
- Test
- Maintain
Furthermore that each was, in fact, a feedback loop to every earlier step, it's really a workflow with only one path forward but many paths backwards. For instance, things found in QA may force a redesign of (parts of) the software and a final deployed system may find that a significant group of users was missed and the entire cycle needs to start anew.
As I said, I knew this spiel well but it doesn't tell the whole story. Implied in the teaching was that it was possible to create software outside of this lifecycle, it was risky but possible. Certainly with the simplistic coding exercises presented that would never see the light of (production) day, it was trivial to bypass most of this lifecycle and jump into a design-on-the-fly build+QA at once model and succeed quite well -- success was measured mostly by visual inspection of the code and 'proof' the software solved the problem (perhaps a demo but more likely canned test data). There was rarely complex code involved and never did the software have to survive for longer than 15 minutes at a stretch with one user at the helm.
I'm not at all sure whether it was this inherent dichotomy in what we did from what we were being taught or not but what I found outside school was typically the same as inside the school. It seems that most people pay homage to the "lifecycle" and expect others to follow it, particularly for Tier 1 software by the likes of MSFT, ORACLE, & Open Text. However, few people feel compelled to do this for "their little software", that somehow they will be spared the need. They are, of course, mistaken.
Recently I have been involved in a customer issue where a piece of custom software was created for them; a very complex piece of software that has required some 3500 hours of effort to date, not all of which has been paid for. The first SOW / expectation was for about 1000 hours of effort, we billed for twice that and eaten a 1000 non-bill work -- what went wrong?
The first and major part that went wrong was right at the very start of the process ... failing to recognize that this project was going to have a Lifecycle for development and ensuring the effort and time is built into the project. You can fairly easily not plan for a feedback loop in your lifecycle, assume that each step will produce perfect output suitable for the next step -- or indeed skip steps altogether -- but that doesn't mean those feedback loops won't happen -- they probably will, it will just cost more when it isn't planned.
Now what fell apart in the end from the customer's standpoint was the performance of the software that was created for them. The functionality was (eventually) fine but it wasn't fast enough. Performance was never mentioned anywhere within the original SOW -- the software that was contracted to be built was built to specifications. What did we do? As a company, we reacted as if we had made some technical mistake, as if the performance issue found uncovered incompetence on our part. However, "performance" wasn't in the requirements and so didn't make it into design considerations and so the build phase wasn't concerned and QA was functional to specifications only (not load testing) and so it wasn't until Deploy or Test phase that this issue was even raised.
One might make an argument that says there was incompetence at the Requirements Gathering phase; however that is to focus on the wrong point here. This time it was a failure at the Requirements Gathering phase, next time perhaps a QA error is at fault or a simple design flaw -- these things WILL happen. No the incompetence is in not recognizing and mitigating the possibility.
If I were reading this instead of writing it I might say something like "so okay, let's assume it is inherent in the process as opposed to simple incompetence, how should that have been recognizable to the SOW creators and what should they have done differently?”
First, it's fairly simple to recognize the situation, it always exists. Full stop. Smaller, simpler projects can absorb a lot to the extent that design/build/QA are all one step and requirements are not even written down -- the lifecycle is still there but it isn't causing significant delays -- all steps are performed by a single person and so merge together well. However, even the first crack at the SOW for this particular customer had 1000 hours (125 days) of work -- I don't believe anybody would and definitely nobody should attempt to "design/build/QA" in one cycle or even with one resource with that sort of scope so we immediately have a complexity not contained within smaller projects. But, frankly, it's more fundamental than even that.
The request for an estimate for the project in anything other than the number of zeros involved (budgetary order of magnitude) is premature and strongly suggests that certain blinders to the software lifecycle are in play.
The key to short-circuiting the feedback loop is to INVEST in the early phases, err on the side of over-investment -- the early stages of a lifecycle are NOT the ones that should be looked at for cost cutting. Recognize that THE MOST EXPENSIVE MISTAKE THAT CAN BE MADE IS AT THE REQUIREMENTS GATHERING PHASE. Sorry for yelling there but its such an important concept that just seems to get missed. Requirements are often gathered by sales associates, solution consultants, and other paper-generators in a non-billable fashion. It is often not work that is included in the SOW; it is the work we do for free so we can write the paper.
Just so I'm clear, I am NOT slamming our good sales associates, solution consultants and other paper-generators for not doing the work -- I know that they typically do a very good job particularly when looked at the time invested. However and at the risk of really annoying you (and because cut-and-paste is easy) THE MOST EXPENSIVE MISTAKE THAT CAN BE MADE IS AT THE REQUIREMENTS GATHERING PHASE. This is precisely where the customer and the vendor should put a lot of effort, followed by the Design phase for the same reasons. You really want to avoid those early mistakes! The first SOW to write should be for writing the Requirements Document and (with something with the scope I have been talking about) should only be for the effort to write a requirements document plus the creation of the follow on SOW describing the effort for the design phase. You should absolutely talk about the other stages to come when creating the first SOW but there is no realistic way you can scope out the effort of the other phases without the deliverable of the Requirements Document.
This is the best money your customer will ever spend and you do no favors at all by skipping this billable activity. As a non-billable activity there will always be a time pressure and a difficulty in accessing the right expertise within your company (there are always a lot of people involved in Enterprise Deployments). The chances for mistakes are greatly increased and in case you forgot THE MOST EXPENSIVE MISTAKE THAT CAN BE MADE IS AT THE REQUIREMENTS GATHERING PHASE.
This same argument extends to the Design phase. The deliverable from the Design phase is a document that coders of any applicable computer language should be able to take and create a piece of software. I would call this the Functional Specification. It should be possible to fairly accurately estimate the effort involved in coding and testing the functional specification (which activity should also be a billable part of the Design Phase). The Design phase should also deliver a technical specification from which architecture and other deployment-related work can be accurately estimated. If you nail the Design phase then you can be fairly sure of meeting deadlines and other milestones for the remaining phases, assuming of course that you nailed the Requirements phase.
As an aside, there is always a desire to utilize pseudo code', 'prototypes' or other coding methodologies during the design phase. While these methodologies are powerful and, with the right audience, can improve and speed-up the design phase, ANY code developed during this phase should be thrown away -- full stop, no exceptions. It was created for creativity's sake, to help understand, refine and prove a design -- design is not coding! That saving of effort (and money) the code re-use is intended to provide is, in fact, not there. Because the code was not designed but thrown together there will be no error checking, missing functionality and even PPT-ware -- the cost of reviewing the code to re-use is probably greater than the cost of writing from scratch (or from other, pre-approved code databases). More often the review won't happen at all (because then the cost savings disappear) and the problems inherent with that decision appear further on down the road.
Coding from good Functional Specifications is really easy, almost mundane -- all the hard work, including algorithm development, should have been done. Design is a senior/intermediate task, coding is a junior task.
So I finish this tirade off as I started, claiming that it is experience that has taught me this not theory. Frankly, if you have ANYTHING to do with the creation of new software and are not familiar with the basic THEORY of a lifecycle, you have no business being involved (except as a business user/owner/purchaser of course). But I think it is only after you have been burned a few times, or listen to those of us who have, that you finally UNDERSTAND the lifecycle. It's unavoidable, the lifecycle exists and THE MOST EXPENSIVE MISTAKE THAT CAN BE MADE IS AT THE REQUIREMENTS GATHERING PHASE. The best thing to do is to INVEST in not diminish the importance of the early stages. If you insist on the impossible estimate before the thing you are estimating is even understood then you will have problems down the road.
The most likely consequence is underscoping the work involved and then corners get cut, less than the best effort is applied, peer reviews and other necessary processes for proper software creation are (fingers crossed) skipped. This is an almost inevitable consequence of underscoping, it isn't a corporate decision or even a deliberate action -- there is no malice of forethought.
Even if the customer would agree to more paid hours, the natural inclination is to try to meet the original estimate because asking for more time is some admission of failure that many seem unwilling to make. As I've argued, the failure wasn't that of the people delivering on the SOW but in the process itself. By explicitly dividing the effort into separately scoped SOWs you avoid much of the problems and certainly the overall risk involved in underscoping; even if you get it horribly wrong, it is only one phase that is wrong, not the whole project.
Kinch
