“No plan survives first contact.” During my days as a young soldier, my platoon sergeant
barked these words incessantly – imploring his troops to prepare for situations as if their
lives were on the line. His message got through. We planned things out painstakingly,
moving plastic soldiers and Tonka trucks around a small sand table. Then we rehearsed
the maneuvers over and over, and before long, we could do them in our sleep.
The sergeant’s slogan applies just as well to the technology battlefield as it does to the
military one. Technology project plans do not need to be rigidly orchestrated right down
to the final detail. But they do need to be thought through, tested and rehearsed before
they make first contact with the marketplace.
Application delivery standards and strategies set frameworks for the successful releases
of products or services. These key components cannot be assembled at the last minute.
They need to be defined by the technology organization well before a project is initi-
ated, and be based on a technology strategy that is focused on delivering business value.
Cloud projects, of course, require extensive planning. Whether you are migrating legacy
applications to the cloud or building new cloud applications from scratch, you need to
develop a technology delivery strategy that establishes the application development
framework, project cadence and production standards. These standards serve as the
foundation for the application, but they need to be flexible enough to avoid being a bar-
rier to team agility. Determining these standards once you are in development, which is
often the case, only increases the risk of the plan not surviving initial customer contact
or release.
The Pros and Cons
What are the benefits of coming to the table with a well-organized plan? Essentially, you
can prepare for unforeseen ambushes – which, yes, usually happen. You can mitigate
cost overruns. You can ease the workload of developers, by allowing them to focus on
building good code rather than carrying the technical burden of establishing/deciding
infrastructure and operational standards. You can develop team cohesion among tech-
nology leaders, operations and delivery groups. You can shorten build-to-market time-
lines, since application development standards are well established before project kick-
off. And by implementing standards and toolsets across technology teams, you can
reduce frustrations, freeing up teams to more easily incorporate new talent to their
product group.
The drawbacks to not entering battle with a well-developed plan are clear. When a
development team, rather than the technology organization, establishes the application
delivery foundation during development, the developers find themselves combating
two types of bugs during test: application code bugs and bugs with development/oper-
ational tools. In addition to debugging code, they are also debugging production pipe-
lines, or logging and monitoring tools, since the first time the team is using these tools
is during the project build. This can result in increased application delivery time and
project scope creep, developer frustration and siloed solutions and decisions on appli-
cation delivery standards.
SUMMER 2019 | THE DOPPLER | 67