Process Mapping Logo

Process Mapping - Methodology

Track Record. Trustworthiness. Competence.

Overall Approach

Overall, our methodology follows the standard software development lifecycle. What we try to create is an effective environment at the start of the process to enable Business stakeholders to be directly involved. One of the main concerns we have had with some projects that we have seen struggle is that specifications are not aligned with both business needs and with the software developers' view of the solution.

We believe that most methodologies, as previously noted, are too technical for the average business stakeholder to truly understand and appreciate. The result is often that the specification is signed off as correct because business stakeholders just have no other option.

Unfortunately, the alternative extreme is no better. If business stakeholders are relied upon to write specifications for software systems, there are still challenges. Mostly these are that the requirements, while being entirely valid, are just not laid out in the logical format that a software engineer will require. Because of this, interpretation is required, and this either causes further discussion, confusion, or assumptions to be made. In extreme circumstances, all three can happen.

What we needed was a way to allow business stakeholders to clearly define their requirements in a way that wholly supports the software development process and is not ambiguous.

We then decided that the scope should not change, and certainly not expand, unnecessarily. That word is obviously too open to interpretation. What we needed was some way to decide what was necessary, and also what measureable benefit it should deliver.

As if that was not challenging enough, we decided that full technical documentation was essential. Although Rapid Development projects are definitely rapid for the first two or three iterations, they rapidly (pun definitely intended) become expensive to maintain and prone to error if complete documentation is not kept up with the code base.

The other problem is that you can easily lose the benefits of Rapid Development if the documentation takes just as long, or possibly longer, than the development itself. Because of this, we determined that the effort required for maintaining the documentation would not only be of long-term, benefit, it would also be as useful as possible in the immediate development process, and require as little effort as possible to maintain.