Using the NoProjects Paradigm

I was involved in building and delivering mission-critical applications for a semi-governmental organisation that provided emergency-management services in Australia. This ICT department was relatively new, hence was not saddled with bureaucratic decision gates and governance procedures. They identified four main applications as the core deliverables that would support the emergency services provided by the field personnel. A select team of individuals was formed consisting of:

• the ICT manager, who also functioned as the de facto ScrumMaster;
• an in-house developer;
• an in-house database administrator;
• a business subject-matter expert (SME); and
• vendor personnel as needed.

There was no project plan with detailed work assignments. There was no assigned project manager, though the organisation does have a sort of project management office that oversees external communications and liaisons. We did no financial estimates or cost/benefit analyses before commencing each mission-critical application, hence we had no approvals to obtain from a peak body such as an estimates committee before commencing the work or when making changes to the system functionality.

The application architecture consisted of four major applications that exchanged data with mission-critical external organisations, such as State Emergency Services (SES), and published information to the community. The applications had to be distributed across a dedicated WAN network so that operational units throughout the state could enter and update their transactional data.

The initial estimate, provided by an external consultancy, for the end-to-end implementation of the four applications was about AU$37 million. The estimate was the result of a month-long engagement with the consultancy organisation. During this engagement, the consultants met with the key stakeholders and IT personnel to gain familiarity with the organisation’s operations and culture.

The IT manager decided to set aside the consultancy’s findings and commence building the applications with the team defined in the list above. Happily, he did not have to negotiate a bureaucratic decision-making process through levels of senior management before commencing. He adopted a #noprojects paradigm in that there were:

• no extensive boilerplate documentation, such as solution architecture or detailed system design, on the lines of Prince2 or other project-management methodology, prior to building the applications;
• no project schedule with defined start and end dates and consequential penalty clauses for not meeting them; and
• no annual budget allocations or approvals from the financial controller.

The team used an agile approach in:

• consulting with the embedded business SME to list the functionality and features of each application, prioritising the features to work on based on business value;
• building the features, both database design and coding, in short iterations (one to two weeks);
• having the business SME approve the feature implementation at the end of each iteration cycle;
• dynamically changing the system design in response to feedback;
• holding retrospectives at the end of each sprint to determine lessons learned and what worked best; and
• releasing to production when a logical piece of work had been completed (e.g., when the functionality for resource type “vehicle” was done in the resource management system, the business SME tested it, and once approved, it was released into production for the end users.)

As mentioned, there were no project deadlines or penalties for not meeting them. The end users for these applications were:

• about 1,200 brigade personnel who entered incidents, resources (vehicles, equipment, etc.), and their response compliance times;
• district, regional and head-office personnel who monitored and sometimes updated the information and generated extracts for external reporting and compliance purposes; and
• analysts who interacted with the applications to report on statistics, trends, and other analysis.

We built the four applications and released them to operations within 18 months at a cost of around AU$3 million — less than one tenth the cost estimated by the consultancy! The production releases had no major issues and they continue to operate successfully, providing value to the business.

Throughout the course of application development, the team adopted a continuous-delivery paradigm of functionality and features. We built prototypes of feature sets in the test environment for the business SME. Once we reached consensus on the prototype, we commenced the actual database changes and coding. We followed this with integration tests with other impacted applications before production releases.

Excluding changes in vendor personnel, the in-house team has remained intact and cohesive, with an average engagement of more than eight years in the organisation. Although such lengths of engagement within the same group may be exceptional for the IT industry, there is a definite advantage in having a close-knit team delivering continuous value. In contrast, when there are frequent changes of personnel within teams, new members must acquire domain knowledge and build new working relationships. This invariably leads to delays and loss in productivity as team members adjust to each other and obtain knowledge and skills.

The team acquired deep domain knowledge as well as close, trusted working relationships with business SMEs. This included the technical personnel, who understood the business processes involved because of their long association with the organisation. Furthermore, the ICT manager insisted that everyone share their knowledge, especially regarding the underlying use cases and business rules. Thus, the team were able to respond quickly to any new or changed business requirements. The team continues to function this way, with high levels of cohesion, information sharing, and client satisfaction.

Finally, a key feature of this approach was the lack of any arbitrary financial overrule on the scope or functionality of application delivery. There was nothing the team needed to submit to a project estimates committee or similar organisational authority to obtain approval before commencing any new application functionality; neither were we saddled with any obligatory outsourcing contracts. The business outcomes were evaluated via feedback obtained from the end users. The ICT manager with the business SME, under direction of the product owner, negotiated for the funding required for the next body of work, which then commenced immediately.

- Max Roy

Max Roy is a driven IT professional who wants to make a difference in businesses. He is motivated to deliver projects that provide business intelligence in executive decision making. 

Max’s career has spanned over 25 years in roles such as solution/data architect, project manager, and IT faculty/trainer. Max has an innovative, pragmatic approach to addressing business needs and end-to-end delivery focus.

Max obtained a master’s degree in IT from The Ohio State University and an MBA from the University of Maryland.