 |
| A phrase spoken on 30 September 1938 by British Prime MinisterNeville Chamberlain in his speech concerning the Munich Agreement and the Anglo-German Declaration |
An epic age-old
battle is raging across the centuries, between good and evil, Microsoft/Windows
users and Apple/OS X users, law enforcement and criminals, Java developers and .Net
developers, blackhats and whitehats, emacs vs vi users, heavy metal fans
and synth fans, orcs and humans, and so on and so forth ..
Fanatics on each
side are entrenched in their legacy experience and convictions, preferences,
tastes - making it impossible to see the other side of the argument, because
it's of course just wrong.
In the project
management context, this typically translates into choosing sides between
methodology approach - waterfall, or agile - with the agile approach having
lured throngs of followers to abandon the traditional waterfall methodologies
for heretical beliefs in happier colleagues, Customers and outcomes working
with Epics, Stories, Sprints and Stand-ups .. and securing Customer (or key
stakeholder) involvement in reprioritization of requirements and scope.
Don't get me
wrong - I sincerely believe that each method has its merits, it's just that the
waterfall approach was better suited to the main bulk of projects I was
involved in during my formative career years, thus making other approaches less
comfortable.
I think most of
you are familiar with the principles of the waterfall model, and perhaps even
some of its origins going back to the very early days of software development,
later to be adopted and refined by the US Department of Defense.
There's a
plethora of sources
online going into all kinds of variants, descriptions of the method etc - so
this won't be a detailed walkthrough recapping such content. Let's just
agree that it typically outlines various stages in a sequential fashion where
the completion of the preceding stages are prerequisites to starting the
latter.
Example –
Preliminary Design, Detailed Design, Coding and
Unit Testing, Integration, and Testing .. or ..
Requirements capture, Analysis, Design, Coding, Testing and Operations
With roots in the
manufacturing and construction industries, the blueprint must be established
before the assembly can begin etc.
A contrarian
approach to the waterfall model, would be Scrum, considered to be one of the
most successfully proclaimed and adopted agile methods. It's iterative,
incremental, and actually encourages the scope and prioritizations to change
with time as the project moves along. Quoting Wikipedia
-"A key principle of Scrum is its recognition that during product
development, the customers can change their minds about what they want and need
.." This is quite different from the waterfall approach as e.g.
changes to solution design discovered during testing would require replanning,
re-"tooling", and reimplementation (you can tell already that it's
costly) not to mention that it may trigger other changes due to dependencies in
the solution.
We'll revisit the
notion of actually involving the Customer continuously in the decision making-
and planning process in a later post, but make no mistake - this is a key
success factor regardless of methodology, it's more a matter of timing, setting
expectations and communicating correctly.
With the
peacekeeper hat on, one is obliged to say that both methods carry strengths,
merit as well as weaknesses - so which one is the wiser choice? None? -
Both!
The
"Pragmatic approach" in my view is to base the choice of method on the
context at hand, and there's a simple perspective which can be applied to do it
- "Goals and Methods matrix". With roots in an academic
paper from 1993 where Turner and Cochrane state that traditional
definitions view a project as ..
- “a complex sequence of activities to deliver
clearly defined objectives ... and the goals and the method of
achieving them are well understood at the start of a project, or at least at
the start of its execution stage”
(Turner & Cochrane, 1993: 93).
(Turner & Cochrane, 1993: 93).
.. - and propose
an alternative view; that a project should be categorized by the extent to
which the goals are more or less clearly defined, together with the extent the
method to achieve the identified outcomes (scope, deliverables) is known.
With such a
categorization, it becomes a little easier to take a step out of the comfort
zone and acknowledge that the favorite method may not be the tool best suited
to the task. Just imagine taking an agile approach to building a car for
each new vehicle ordered (low production rate ..) or applying the waterfall
model to exploratory research (let he who hasn't exceeded his budget cast the
first stone ..)
Sometimes, even a
mix between the two (usually described along the lines of a v-shaped spiral)
might be the most productive strategy even though it may send chills down the
spine of puritans.
At Enfo, we support our Customers with a similar
approach when it comes to digitalization
initiatives and capturing the value of innovation, which often take the
shape of a technical solution implementation project in combination with an
organizational change at the same time. Changing
the way you do business and interface with Your Customer
can rarely be accomplished within the same organizational setup as the vehicle
taking you to where you are today. Hence the need to address both areas,
which is likely to require slightly different choice of method.
The industry
trend of viewing and categorizing investments through the "bi-modal lense"
(fast/slow, marathon-runners – sprinters, ninja-samurai, innovation/operations)
is also enabled through this method approach.
It's not a
question of abandoning your faith, making a deal with Hitler, selling your soul
to the Devil, or giving up on your principles - but - at the start of your next
assignment, try to map out where your organization, project and goals fit in on
the matrix and keep an open mind on how to approach the choice of project
method thereafter. Perhaps it’ll take us a step closer to peace for our
time!
By Fredric Travaglia, Business Development Consultant @ Enfo
https://en.wikipedia.org/wiki/Waterfall_model
https://en.wikipedia.org/wiki/Scrum_(software_development)
Turner, J.R. and Cochrane, R.A. (1993) “Goals-and-methods matrix: coping with projects ill-defined goals and/or methods of achieving them”, International Journal of Project Management, vol.11, no. 2.
http://www.enfo.se/
http://www.enfo.se/Den-Digitala-Dimensionen
http://www.travaglia.se/2016/06/id-like-two-scoops-of-change-please.html
http://www.travaglia.se/2015/10/who-is-your-customer.html
http://www.travaglia.se/2015/11/let-trend-be-your-friend_24.html
http://www.gartner.com/it-glossary/bimodal/
http://www.thedigitaldimension.com/Posts/Video-Logs/2016/Innovation/Create-and-capture-value-in-the-digital-dimension
