After all the progress that has been made in developing software, one would expect that developing software should be a simple, step by step process. Like other engineering processes, the software development process also would have its checks and balances in place, and there would be a greater predictability and control. However, in practice it is hard, as the project failure statistics show (reference 1, reference 2, reference 3). Could it be because the project management is flawed in execution, or could it be because it is rendered less effective for software development because of some inherent issues with the software development process itself?
As we shall see, due to the way software development process is carried out, project management is often blindfolded. Consider below a couple of basic questions:
What is the actual working of the software?
What is the percentage progress of my project?
Generally it would be simple to answer those, right? However, in case of software development, the answers are mostly some kind of guesswork, and like any guesswork, they can be right sometimes and wrong some other times. Let’s see why.
Working: The developer who can describe the exact working of the system is typically the one who implemented the functionality. When that developer leaves the team, some tacit knowledge is lost. There are significant limitations to capture this kind of tacit knowledge in some kind of documentation. Therefore a successor finds it extremely hard to gain that level of mastery, and the project suffers because of that.
Progress: The manager asks the developer what is the % progress. Whatever answer the developer gives is fed into their spreadsheet or tracking software, and number crunching is done on that. Note that the number is used as it is because there is no way to cross-verify it. Some times the developer is in the midst of some deep problem-solving and gives some number without much thinking. In other times, there is always a possibility that the developer missed some important aspect of the functionality which could invalidate the number at a later date.
The point is that the critical information such as this is hidden somewhere deep inside the code. The gap between reality and reported numbers keeps growing with project size and age. Indeed, the Project Management Statistics article quotes Gartner that larger projects are more likely to fail. What else would one expect when the management has to operate blindfolded on the basis of guesswork? How can the best of management help this situation?
Fortunately, a solution is emerging in the form of Xsemble. Xsemble deals with exactly those parts of the software development process where one is blindfolded. It brings to surface the critical information that was hitherto hidden within the code. Combined with the other activities which are neatly handled conventionally, we get an end-to-end process of developing software that runs smoothly. The enhanced process provides better visibility, helps you identify and deal with risks better; and generally helps you steer your project to success with more certainty, more confidence.
Here is the Process Flow Diagram of this new process.
For a detailed explanation of this process and the various ways in which it can be used to the project’s advantage, please refer to our white paper. The white paper also suggests 10 ways in which one can use the new information to understand and control the software development process.
If you have any questions / comments / concerns, please use the comments function below. If you need help in applying this process on your software project, write to us at email@example.com.