Estimating and delivering defined outcomes

Recently there has been a shift away from time and materials projects towards defined outcomes, driven by various legislative changes, specifically IR35, but also cost control in the procurement function of larger organisations.

This type of project shifts risk from the procuring organisation to the delivering one; they are now responsible for delivering a specific outcome for a pre-defined price. If the project is more complicated than initially thought but remains in scope, the delivering organisation owns the cost.

The key to reducing risk is explicit project scoping, communication to minimise assumptions and accurate estimation.

The Team

Before any activity the time requirements on all of the project stakeholders, domain experts and delivery team should be made clear. Building a truly combined team that combines technologists and organisational expertise is key to managing delivery risk. Keeping decision makers close to the process reduces feedback loops and keeps the project on track. Building relationships and understanding early in the projects simplifies resolution of any issues.

Spanish rugby team

Project Scoping

Organisations embark on projects for the outcomes that they deliver, not to create a piece of software. This may seem obvious, but without a clear understanding of the context for the project being delivered, there is little chance of project success.

Wherever possible, the team should work through a discovery process with a client, starting with user needs and then getting into more detail. For smaller projects, the discovery can be an afternoons workshop, and for a more complex project it could be an entire sprint.

Significantly at the end of the project, there should be an output that is detailed enough to allow the delivery team to estimate the delivery process. The delivery team should also be involved in the discovery process to ensure that all assumptions are clarified.

Communication

Once the scoping activities are complete, and the output documented it should be presented back to the client. Reading back the teams understanding in this way, makes sure that all of the stakeholders are aligned. The output of the discovery process must be presented instead of being sent to read.

Accurate Estimation

There is an apocryphal tale of Roman engineers being made to sleep under bridges after construction or made to stand under the bridge as the first legion marches over. The closest actual reference to this is a little oblique, from a famous roman architect Vitruvius talking about a law in Ephesus that holds architects responsible for their works, that didn’t exist in Roman law.

[...] When an architect [in Ephesus] was entrusted with the execution of a public work, an estimate thereof being lodged in the hands of a magistrate, his property was held, as security, until the work was finished. [...] But when more than one-fourth of the estimate was exceeded, he was required to pay the excess out of his own pocket. [...]

This is a key part in having the same team that estimates the work be responsible for the delivery, if there is any disconnect, even with the best of intentions, will lead to issues. Any team estimating will naturally base that estimation on their own competencies and experience; this may not precisely match another team. Also, knowing that you are personally responsible for an outcome does clarify thinking wonderfully.

The Puente Nuevo (New Bridge)

All of this planning and discussion can start to sound like Big Up-Front Design when companies are embracing agility. The key to remaining agile is to plan at the right level of detail, normally themes for a sprint, and then time box delivery on that theme. Time boxes create a mechanism for quantifying the level of investment in a particular theme or feature while still allowing agility in the details.

Issue Resolution

Creating an integrated team that includes domain experts and decision makers reduces the number of issues that arise. If issues still arise then strong team relationships and commitment combined with direct communication ensures they are resolved rapidly before any snowballing can occur.

A strong team can also deal with changes of scope and any resulting re-prioritisation, rapid feedback to decision makers ensures that all stakeholders remain aligned with the project outcomes.

Suitability

This way of working is not suitable for long running projects which would likely benefit from a more Kanban/Lean approach the focuses on throughput and efficiency instead of immediate impact.

Conclusion

Team continuity from the start of a client engagement through discovery, estimation and delivery reduces risk for both client and agency.

Sustainability - engineering a sustainable future

At San Digital, we believe the work we do today should positively impact the environment and not compromise the ability of future generations. It seems obvious, but large organisations continue to think sustainability is a box-ticking exercise and an inconvenience.

Agile Businesses

There are more than enough articles about agile software development; this post is about agility elsewhere.

Jumping into the FHIR - type systems and objects

We have been doing a deep-dive on FHIR implementations and tooling following our initial FHIR investigation. A critical area of investigation for any system, particularly a large distributed system with many clients and peers that need longevity and guided evolution is its type system. Use of a strict type system can have many benefits - interoperability, governance, data quality, security, performance, developer experience, reduced component complexity and the ability to evolve services with confidence

Integrating with Events

The San Digital team has worked with numerous organisations in both the public and private sectors to transform their applications architecture into a flexible and business-focused model. Working with events at scale is key to maintaining individual teams' agility.

The process of building a mobile app

The team at San Digital has extensive experience developing apps for mobile devices, smartwatches, and smart TVs; using native and hybrid technologies (and everything in-between!) including using Rust for complex comms.

Low friction development environments

While setting up a sample project from an unnamed large vendor the other week I was disappointed by having to read large amounts of documentation and run various bits of script to install dependencies and set up infrastructure. We live in a world that has tools old (Make) and new (Docker) that can be combined to make onboarding engineers low or zero friction.

Cloud-native FHIR platforms

Continuing our series of posts on web protocols, we have been investigating more specialist protocols, in this case, "FHIR". We have produced a document based on our research, investigations and experience.

Team Structures

Multiple team structures can work to deliver software projects. There is no real one size fits all, however, there are common components that can be seen across different structures. At San Digital we believe that Engineer-led teams deliver great results for short duration high-impact projects.

Rules of the Road

This is called rules of the road but they aren't rules they're more guidelines, so they're rules until there is a good reason to ignore them.

Estimating and delivering defined outcomes

Recently there has been a shift away from time and materials projects towards defined outcomes, driven by various legislative changes, specifically IR35, but also cost control in the procurement function of larger organisations.

The San Digital Stack

San Digital has been designed as a remote first business from inception, on the assumption that it's easier to add offices later if they are necessary in an agile way. To work in collaborative way completely remotely takes a carefully thought out set of tools. Some of the ones that we use are really standard and some are a little more interesting.

Test driven design, or planning driven development

Design processes in most business software development resemble peer review or crowd-sourcing. A putative design is presented to peers, who will do their best to find problems while the originator of the design defends it against these challenges. Ideally, where they are demonstrated incorrect or incomplete the process will iterate and an updated design produced and defended.

A human view of computer vision at scale

Computers analysing and acting on what they see is not science fiction or even a new concept, it has been a reality of humankind's drive towards hyper-efficiency since around the time I was born.

Building scalable frontends

Scaling frontends is hard, actually scaling all codebases is hard, frontends just happen to be particularly visible and have a tighter feedback loop and a higher rate of change. As with all codebases, it is in principle possible to scale development through standards and integration processes, but these are a poor substitute for communication. Once development moves beyond the scope of a single team, either progress slows to take into account of different processes or implementations drift away from each other over time. Teams need to find a way to operate independently towards a goal.

Cross platform native mobile development with Rust

San Digital have extensive experience of mobile development and the use of Android as an embedded operating system. We treated android as a deployment target target for Rust firmware as well as writing our intricate real time communications component for both iOS and Android. This approach has advantages, you can maintain a single code base for a complicated communications layer, while also taking advantage of the full native capabilities of each platform

The evolution of web service protocols pt 2

At San Digital, some of us have been building things for people since the dawn of the web. Our historical perspective helps inform us about technological culture and trends today, almost compensating for the creaking knees.

The evolution of web service protocols pt 1

At San Digital, some of us have been building things for people since the dawn of the web. Our historical perspective helps inform us about technological culture and trends today, almost compensating for the creaking knees.