Software development is not trivial.  It is a highly complex process and yet do we continue to act like it is something we have done many times before.  When we then realize during our post-mortum that we did not deliver what we expected to deliver within the budget we agreed to, we believe that the reason for our lack of success is that the people working in the project are not following the process as we have described it.  This leads us to reviewing the process and tweak it in those areas where we find the process to be unclear or not detailed enough.  After the adjustment we use the new process for the next project, only to realize in the next post-mortum, that once again we need to adjust the process and re-iterate to the team what the process is and that they have to follow it.  We describe in details which steps the team must follow, which phase-gates that must be adhered to and when sign-off is required.

We provide the team with our standard templates that we have created and adjusted using all of our past project experience.  We keep adding more and more details into the documentation to ensure that our clients understand what they will get so that they can sign-off on the documentation.  To have this process makes us feel good and we pride ourselves by having a well defined process that is well documented and should make us more successful.  With client sign-off on key documents, such as Scope-, Requirement-, Design-, Configuration- and Testcase-documents throughout the entire project, we feel secure.  And should the unthinkable happen that the client is not happy with what we deliver, then we can always go back to the documents that they signed off on and prove that we delivered what we promised; it will even hold up in court.  But is that really what we want and how we define our success’s?  By making sure that we can win in court?  Should it not be the happiness of our clients that defines our success’s?  We claim that that is the case, so when the client is not happy and threaten us with lawyers and change of partners, we often go down the path of giving away hours for free and hope that this will make the client happy.  But most clients do not care about getting hours for free.  They would much rather have the software they need when they need it at a reasonable cost.  For clients, the cost of not having the systems in place that will support their business-needs better is often 100-fold more expensive that running a project that is delayed again and again.

In all of the projects I have been part of for more than 15 years, I have never seen a project where the client did not change their mind at least a couple of times during the project on what they wanted and when they want it.  This change in scope and requirements causes delays and extra effort in the project because we now need to adjust all the documentation we have done, get new sign-off and re-start the project again with the new goal defined.  Often we will have to find ways to stay within the original delivery deadline as we agreed with the client on.  This then often leads us to find corners we can cut without compromising the entire project.  So we cut scope; we tell the developers to ‘just make it happen with less time available’;  we decrease the time that we had set aside for QA and still believe that the quality of our product will stay the same as the original plans.  Maybe, and only maybe, are we able to deliver something within the deadline, but how do we make sure that what we deliver is actually what the client needs?  I have seen many many cases where we have over-delivered in one area but totally missed out in other areas that were more important to the client, simply because we only have on focus and that is to follow the project plan;  then when we run out of time, those areas that were important to have delivered have to be dropped from scope.  In many cases it would have been better to delivery ‘thinner’ functionality in some areas, to allow for all areas to have features delivered.

I think most people can recognize the scenario I have described above and most people will agree that not two projects are alike.  So why do we, after 30+ years of experience running software projects, still believe that if only the team would follow the process that we have defined, then we would become successful?  That the process is correct but the execution of the process is wrong?  Why are we still making the same mistakes over and over again without learning from them?  But we do learn do we not?  Is that not the reason why we keep tweaking the process?  Because we become wiser and wiser.  I will risk the blame and claim that we do not learning from our mistakes.  We keep doing the same mistakes over and over again and we blame the wrong things for our failures.  It is time for us to realize that it is the process that is wrong and not the people following the process.  Remember, we are not building the same gizmo over and over again.  We are building net-new functionality every time we get a developer involved.  “Not true” some would say; “we have build the same functionality for several clients, so we must be able to estimate the effort, within 90% probability, that we needed to build it again for this client.”  So my question then is “if we have already built the functionality for several clients, why do we then need both architects and developers to be involved?”  Is it not the case that every time we build functionality, we are in fact building net-new functionality?  Is it not the case that no matter who detailed we describe a feature in our design documents, we still miss the target with what we deliver?