My Objectives were:

• To change the culture from one that was inward-looking (every problem is solved by writing some code) to one that considered external commercial or Open Source solutions (a problem can be solved in many different ways).
• To reward outcomes rather than inputs, i.e. the primary concern is that the project objectives, the deadlines and the architectural principles and standards were all met.
• To allow developers some freedom to choose their projects
• To encourage information sharing, collaboration and cross-skilling within the team
• To reward the top performers and manage the poor performers

This looks like a lot to ask from a single process with a simple measurement system, but I believe that the process we have selected should achieve all of these.  Firstly it is necessary to note that I have created three development teams who are accountable for progressing our technical strategy and defining standards and toolsets within their respective domains.  These are the “Front-Ends” team which includes the web-team, the Integration team, and the Services team.

The RFP Process

• At the Project prioritization forum the Business-Unit heads agree the priorities of the projects for which we will publish RFPs
• The Project office prepares a very brief RFP describing the key outcomes required for the project.
• As the CIO, I estimate the size of the project and award the project a size-value on a scale of 1-20.
• The RFP is published on an internal blog indicating its size-value and priority.
• The developers are notified of a new RFP and may then respond to the RFP or form a syndicate across the various teams to respond to the RFP.  Only two days are allocated for the construction of a proposal at this point in the process.
• The responses are considered at the weekly Architecture council meeting (Chief Architect, Head of Operations, Heads of each development team, Data & Services registrar) in terms of the quality of the technical approach, the reasonableness of the effort estimate and the time-to-market vs architectural-significance trade-offs.
• One syndicate is awarded the project and must take into consideration any guidance offered by the architectural council.

The Planning Process

• The syndicate should then embark on a detailed estimation process which follows a Delphi methodology to arrive at a fairly good estimate of effort.
• A detailed design process is worked into the plan and after the design is complete the effort estimates are reviewed one more time.
• The project is baselined at this point and deadline targets are measured based on this iteration of the project estimation.
• Depending on each syndicate members involvement after the estimation the project-size units earned by each member is adjusted if necessary.

The Project Scoring process

• Once the project has been completed it must be scored by all the relevant stakeholders.
• A standardized electronic survey with a set of questions for each type of stakeholder is used, so that scores can be easily compared.
• The standardized questions are published so that everyone knows in advance what the required outcomes are.

The Performance  Measurement Metrics:

Using these measures the following can easily be measured and managed:

• Each individual must have earned at least 20 Project size points in a year.  I measure this on a prorated basis every quarter and meet with underperforming team members to help them get back on track.
• In order to qualify for a bonus each individual must earn at least 24 project-size points in a year.
• Of those eligible for a bonus, their individual Aggregate Project Outcome Scores  (Sum of (earned Projects Size-points x Project Survey Score) for all the projects an individual was involved in) determines their rank on the Bonus list.  Top 5 scorers earn 15,14,13,12,11% of the development team bonus pool respectively, and the balance of the eligible team-members share the remaining 37% as a ratio of their relative scores.

Performance Reporting

Although all this may sound complicated it reduces each team-member’s score to two metrics: Project Size Points and Project Outcome Scores.

• If you have more than 20 Project Size points you keep your job. 
• If you have more than 24 Project Size points you will get a bonus.  
• The size of that bonus is determined by you Project outcome Scores (The quality & timeliness of your work)

The current scores for each team member (both size and outcome scores) are published weekly for all to see.  No-one should have any doubt where they stand at any point in the year.

Some Balancing factors

Of course none of this works if there are insufficient projects to keep everyone busy during the year.  It would not be fair if there were not enough project-size points available to ensure that everyone can earn their required 20.  Fortunately I do not anticipate that scenario for many years to come.
I am sure that by the time that occurs humans will no longer be involved in software development processes, and performance measurement will have a completely different set of objectives.

A Smart-client can address many non-functional or repeating-requirements that will not have to be developed ever again.

Smart-Client Administration
An administration Interface for the smart client is essential to take admin away from the developers and hand it over to the support desk. For instance adding a new user or promoting a piece of functionality from Testing to Production can be done via an administrative interface. Within this client we embed a lot of functionality that would previously have been done by developers. I include Authorisation, creation of Data access aliases (See section on Data Access Agent), upload of new functionality into the Smart-client database, promotions between Development, Testing, Production etc, notifications to authorised users, work-flow definition and edits, creation of aliases to access functionality (menu-item naming) and any other administration whether done by developers or support-staff. I also recommend that the admin tools be built as functionality that snaps into the smart client itself – it just makes it easier.

Authentication / Authorisation
If your organisation uses a directory service of some sort, then integrate the smart client into the directory for authentication. If you have a generic authorisation services, then use that to authorise the client functionality as well. if not, link the IDs of your directory user into an authorisation table accessed by the Smart client Administration interface to link users to the functionality they require.

Work-flow
If your organisation uses work-flow, then definitely link generic work-flow functionality into the smart client so that it too is dealt with once.

Data Access Agent
If your smart client allows plugged-in code to access data directly, then you are missing a trick here. This idea has very powerful side-effects.

Define a method by which plugged-in code asks a function provided within the smart client for some data. The smart client should then source the appropriate data and return it to the calling plug-in. Some side-effects here are that the developers need not know any of your production database user-names or passwords, and you can within the smart-client infrastructure redirect data requests to other destinations (for example to your disaster-recovery site, or a testing database)

In the implementation I have built previously, we created a lookup-table for data-sources that indicated an “allowed calling-plug-in”, “operational-mode” a “Data-source alias” and the details of each data source. This allowed us to automate a switch to “Disaster-Recovery” mode through using a predefined “operational-mode” called “DR”. The Smart-client had a process for checking against a centralised web-service for which mode it should be operating in for a particular application. The flexibility here was staggering. This also means that the change management team can promote an program from Testing to Production without any help from a technical team whatsoever.

On-line/Offline modes
A web-based client or portal has the disadvantage that offline modes are not possible or at least very difficult to implement. A smart-client can do this fairly easily and with the “data-access agent” functionality above it is even easier to achieve.

Code Generators
I have found that most user interfaces that we needed to build were in fact forms that interacted with data-tables. We used a multi-tier architecture where the front end was smart-client (containing a data-access layer), a business layer consisting of stored procedures which performed a lot of the business activities and which interacted directly with the data-tables. So we created a form-builder that created both the stored procedures and .NET forms automatically. We would point the tool at a set of data-tables and lookup tables do some configuration and click “GO”. What we got out was a stored-procedure that conformed with all the rules we had predefined and a .NET project with all the necessary forms and the interactions with the Data Access Layer and Stored Procedures. If there were no fancy custom UI interactions nececessary we could simply compile the project, and upload the DLL into our smart-client database for testing.

So no developer-time required for:

• authorisation,
• basic form-based UIs,
• access to data,
• Disaster recovery implementations,
• promotions between Dev, QA, Prod etc,
• Creation of menus
• Creation of custom workflows

among others. This represents a significant saving in the development stage of any project.

Technorati Tags: Software Factory, Development, Custom Code, Code Generation