|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
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.