From Specification to Implementation (III)

Continuing with related post (From Specification to Implementation) I will described the last processes implementation in a public organization supported with RedMine.

The final photo (today, forward work will be done) consist on:

A set of processes:

• Project Planning (CMMI)
• Project Monitoring and Control (CMMI)
• Requirements Development (CMMI)
• Requirements Management (CMMI)
• Release Management (ISO 20.000)
• Defect Management 

A group of roles (RedMine roles):

• Sponsor
• Expert User
• Functional Director
• Project Manager
• Project Team 
• System Manager
• System Team

And several management elements (RedMine trackers):

• New Initiative
• Goal
• Project Plan
• Requirement
• Requirement Change
• Sprint
• Release
• Version
• Defect
• Request for Change (development)

With these three group of elements the new methodology is ready to be used. The relationship between then is described in the following picture:

Further related documentation have been generated: templates, reports, user manual, change management... and everything is supported with wiki and document functionality.

From Specification to Implementation (II)

Starting from previous post, several approach could be done to get a process implementation in any organization.

From our experience, the process implementation consist on the following main steps:

• Initial Situation: this set of task consists of several techniques and work focus on identifying organization needs, how the organization is working, strengths and vulnerabilities.
• This work generates a document that identifies such things and propose a improvement process divided in three scenarios.
• Process Implantation: once the goal of the first implantation has been defined, the work will be lead by defining working group for each process, in order to identify in detail how tasks activities are being delived nowadays, and how could be unified, attended and systematized to reach users needs and organization goals

Process Implantation finish when the organization has several process implanted with:

• Entries
• Outputs
• Tasks
• Roles
• Reports
• Metrics
• A tool or a set of tools that support it
• Training sessions - Change management
• Initial support

From my point of view the supporting tool is the key to organize any process, and it will allow:

• Monitorization
• Measurement
• Regulation
• Support
• Collaboration

Any ticketing tool will help to fit your needs, we have used RedMine as project management tool and we have good experiences with it.

Testing and Development: sustainable economic model

Test processes increase total cost of projects

This sentence could be the started point for a long discussion about truth and false that have to be analysed in detail.

• Development teams should test every version, if we have a independent testing team for version verification, then we have increased total cost.

This affirmation is true and there is no much to add, the key concept that we have to realise is that this cost should be budgeted from the early beginning and also it should be in our project plan. Another point is that testing cost should be something less than 15% of development cost.

•  Where is the advantage of testing? Do they improve software? Which is ROI of every euro spent in testing?

There are specific economic models to show the value of testing, and how 1 Euro spent on testing will save several in maintenance, operation, codification... it depends on when you invest on testing, as early you start as much money you will save

• As there is a testing team, developers are lazy testing their own work
• ... 

The main goal in the last months in my job has been to define a sustainable economic model  that allow business to have the benefits of testing with a predictable cost.

The model is sustainable with the following concepts:

• For every software version we will know development cost and testing cost.
• For every delivery of the same version we will have two metrics, derived from testing:
• Number of corrections until the software has been deployed in test environment.
• % of requirements passed as ok after testing is finished
• Two indicators and two slas are associated to these metrics:
• Number of corrections have to be less than X (for example three)
• Fulfillment of requirements have to be greater than Y (for example 75%)

With this, it is possible starting a new version and the development team will estimated the cost (ie 100.000,00 €) and the testing team also (15% - 15.000,00 €). Then, when the first delivery arrives:

• If both indicator are better than expected by the sla --> total version cost will be 115.000,00 € and the first version is a good candidate to be  promoted in a production environment (it will depend, but could be)
• If any indicator is worse than expected --> a new release will be delivered, test cost will increase, but development team will be penalized --> (100.000,00 - 10.000) [Developement] + (15.000,00 + 5.000,00) [Testing] = 110.000 €

With this model, as many release are needed less development cost  and more testing cost, the total cost should be constant for final business.

Continual Improvent Process

The continual improvement process is almost the most important concept that every methodology must define, and that should be always implement in any organization.

If we take a look at most significant methodologies, we can see this process area definition:

• ITIIL V3
• CMMI - Dev - 1.3
• TMMI

Continual Improvement Processes aimed to be used not in an initial application of any of these methodologies, but in a later step, and this causes several miss-performance situations in organizations:

• Organizations that are making an effort in methodology improvement don't have a continuous improvement process included on their process map.
• After implementation of the methodology in the organization there are no metrics to determine if performance is increasing or not.
• Basic diagnostic is not determine: is the methodology in my organization being used?

To avoid those situations any implementation of any methodology must define a set of processes, with almost the following matters:

• A set of processes not in paper, but with a computer based solution that support then.
• A set of basic metrics that measure how are  being used processes.
• A set of performance indicators to determine if throughput is increasing or not.
• A set of reports that inform the methodology leader how everything is going on.
• the organization must know how to inform or propose improvement  to methodology.