Agile based project management

Drive Your Business
Agile-Based
Project
Management

2 ©2016 WGroup. ThinkWGroup.com
The battle of Verdun in 1916, during World War I, lasted nearly nine months and resulted in
the deaths of about a quarter million soldiers (one million wounded). A new battle, the battle of
Somme, was then started as a means to draw German forces away from Verdun. In the end,
the Battle of Somme resulted in one and a half million additional casualties with around four-
hundred thousand killed. Talk about remediation! By the time this new three month battle ended in
September of 1916, the British and French had managed to perform an “impressive” drive of only
five miles. This comes to about fifteen human beings killed for each foot of ground advanced!
Non-withstanding the fact that the butchery
of these battles remains a paragon of
human stupidity even to this day (and
that’s saying a lot given all that has
happened since WWI), there are some
lessons to be learned here. Verdun and
Somme were probably on track from
a task-oriented, project management
perspective. One can imagine the
generals using one of these popular task-
oriented project management tools to
“manage” the battles: “Delivery of supplies?
Done!” “Digging of trenches? Check!” Transferring another division of five-thousand
men to the front line to serve as cannon fodder? In Progress: Green status!”
We all can think of some large IT projects that have faced their own version of the
Somme’s battle. Imagine instead, if there had been quantifiable milestones, e.g. “By week
two we should have advanced five miles”. Perhaps that approach would have served
the war “leaders” better in understanding that their “project” was headed nowhere.
Introduction
Is your project a losing battle?

What happened in Verdun and Somme is typical of many failing projects: doubling
down on failure in the hope of a different outcome. This type of behavior has been well
observed under the guise of the Gambler’s Paradox—continuing to gamble in the hope
of recouping losses; resulting in even greater losses. Good project management, on
the other hand, entails tracking down and detecting when a project is being derailed
and then planning appropriate, timely remediation or even changing direction. This is
why it’s best to properly partition a project into discrete and well quantifiable milestone
targets. At least in this way, if something fails, it will only affect a portion of the effort.
Focusing less on micro-managing every activity and more on enabling the timely delivery of
milestones that break-down the project into specific sub-projects is a more flexible approach.
Milestone targets will help reveal
true progress – or failure.

Handling issues occurring at a sub-project level is less difficult. Also, having stand-alone
milestones allows for possible early delivery of actual functionality. It is even possible to
create some milestones to serve as a “canary in the mine”, as long as these milestones
do not create unnecessary pressures or distract from the main path of the project.
Needless to say, the key to tracking and assessing the status and impacts of a project’s
dynamic is the project management function. However, there is the mistaken idea that
anyone with working knowledge of MS/Project can become an IT project manager. The
fact is that in the world of IT, delivery managers with systems and software knowledge and
background have traditionally been more successful in the project management role. Perhaps
the reason for this is because this type of project manager is more able to assess the health
of a project against actual milestone deliverables rather than via traditional Gantt charts with
red-yellow-green status colors. This semaphore style might look good on status reports but
does little to ascertain the true project status.
When establishing the project
management governance, keep in mind
that there are projects and, well, there
are projects. Smaller projects have to
be handled in a manner that assures
the necessary ingredients for success are available
to the team leader with a minimum of red tape. Smaller projects can benefit greatly from rapid
application development methodologies1
and from early prototyping. In addition, smaller projects
better align with the iterative approach favored by Agile methodologies. Partitioning a large project
into smaller areas of work also facilitates the potential testing and introduction of innovative
solutions while minimizing risks. However, partitioning should not be viewed as “fragmenting”.
There is science and art in the way to partition a major initiative while maintaining a holistic and
integrated view of the whole. In this sense, the principles followed in Agile development (planning
game, small releases, simple design, ect.) also apply to milestone-based project management.
1 NOTE: Use of Agile methodologies should apply to the actual software development process; not to the
architecture and design-making processes. Using pseudo-Agile approaches under the mantra of “code now,
design later” often results in failure.
In the world of IT, delivery managers
with a systems and software
background have traditionally
been more successful in the project
management role.


Well, having no more than five people working on a deliverable for a maximum of four months is
as good a metric as any. If the cost of this type of project exceeds the one million mark including
labor, hardware, and software capital costs, then it should not be handled as something small.
Then there are the medium size endeavors. These are projects that can take up to a year, or
slightly longer if the powers-that-be are willing to take Prozac and give you a bit more leeway.
The core development teams for this type of project should never exceed the magic number
of twelve. These projects tend to fall in the ball-park figure of around two to three million
dollars. A medium size project needs to be managed with a savvy combination of high-level
project management controls and the appropriate placement of deliverable milestones.
What defines a small project?
Larger projects should not even exist. Why not? Well, a large project should be properly broken
down into as many small and medium sized projects as possible. Ultimately, a large project should
only exist in the Powerpoint bullets of those responsible for your company’s public relations, in
the minds of marketing (“Version 3 of our Super-duper product available by Christmas!”), and in
the radar of the very small team responsible for the integration of all the various moving parts.
Clearly, the failed initial launch of Healthcare.gov was an example of a humongous
project that was managed on a task-oriented basis. It had only one real milestone: Go into
production by October 1, 2013. We all know what happened next. The story would have
been turned out a lot differently if a milestone based approach had been followed.

Basically, it’s the definition and tracking of measurable, well defined milestones. Note that we are
not suggesting that the need to plan for tasks goes away; just that the project status should not
be measured vis-à-vis the degree of task completion or the amount of hours worked on a task,
but rather against the milestone’s success or lack of thereof. Milestone management is based on
outcomes as compared to the actual business requirements the project is attempting to solve.
The difference between a milestone and a traditional
project management event is that the milestone
should stand on its own as a visible deliverable.
Visible is the operating word here. Completing a
piece of code is not a milestone. Completing a
working prototype or demonstrating a working sub-
component of the deliverable are proper milestones.
An eye-candy demo is not. If the event is something
that can be shown to anyone outside the core
development group, and is considered to be at least
a partial success, then it qualifies as a milestone.
So, what is agile-based project
management really all about?
The difference between a milestone and
a traditional project management event is
that the milestone should stand on its own
as a visible deliverable.


There is no way to sugar-coat a missed milestone. While this should not
necessarily spell gloom-and-doom, a project with two or more missed
milestones is a project that needs to be seriously reviewed and revised.
Tracking projects via milestones has a number of benefits:
• Missing a milestone might be a clear signal that the project is not on track,
but the impact of the delay can be contained in a more timely fashion
• A successful milestone motivates the team by providing success checkpoints
• Milestone deliverables with stand-alone utility can deliver actual benefits sooner
• A successful milestone helps motivate the project sponsors to continue their
support of the project even when faced with budgetary constraints
To be sure, it’s always best to allow room
in a large project to anticipate the failure of
a specific component and to adjust for the
overall delivery because of this failure. The
solution to this type of quandary might range
from starting again from scratch (assuming
the initial implementation was proven wrong),
to completely eliminating the subsystem and
remediating by providing a suitable minimum
set of capabilities from other subsystems.
Ultimately, it is sobering to realize that the kind
of flexibility provided by agile-based project
management could have avoided the tragedy
of Verdun. The good news is, we can all learn
from history the best way to win our battles.
Conclusion

Israel del Rio is an executive and technologist
with over 30 years of practical experience
in global IT and digital transformations
for both, large international companies,
and well-funded start-ups. He has led the
delivery of innovative solutions in close
collaboration with business stakeholders,
resulting in several million dollars capital
and expense reductions. As CIO and
CTO, he has led large geographically
distributed IT teams, and defined enterprise
strategies, system architecture, IT
governance, led large outsourcing deals,
and implemented various business solutions
via Agile and Waterfall methodologies.
Author: Israel del Rio, Principal
Israel is a well-known IT leader in the hospitality
industry and is driven by significant and
measurable results. In addition to IT Leadership
and Management, Technology Transformation
and IT Strategy & Architecture, his knowledge
areas include Social Media and Cloud/
XaaS, Cognitive and Data Science, B2C/B2B
eCommerce, CRM/BI, Software Development,
SOA, and Performance Management.
Prior to WGroup, Israel held key leadership
positions for global companies, including SVP
& CIO at Revel Entertainment LLC, SVP &
CTO at IHG - InterContinental Hotels Group,
senior advisor for Mexico’s Grupo Posadas,
SVP of Technology Solutions at Starwood
Hotels & Resorts Worldwide Inc. and VP
of Architecture & Engineering at Sabre.
Israel is fluent in English and Spanish and has a
BS in Electronics & Communications Engineering
from the Instituto Politécnico Nacional, México.
He has won multiple awards throughout his
career, including 2007 Computerworld Premier
100 IT Leader, InfoWorld’s 100 Innovative
Solutions Award in 2002, Division Award for
Galileo, Award of Merit for United Airlines, and
IBM Marketing Excellence Award. He engineered
and developed the new infrastructure for O’Hare
Airport Terminal 1, including over 1,000 of the
first-ever diskless workstations connected
via complex local area networks. He is also
the author of Technology Transformation—
Trials, Techniques & Tribulations.

Drive Your Business
Founded in 1995, WGroup is a technology management consulting firm that provides Strategy,
Management and Execution Services to optimize business performance, minimize cost and create
value. Our consultants have years of experience both as industry executives and trusted advisors
to help clients think through complicated and pressing challenges to drive their business forward.
Visit us at www.thinkwgroup.com or give us a call at (610) 854-2700 to learn how we can help you.
150 N Radnor Chester Road
Radnor, PA 19087
610-854-2700
ThinkWGroup.com

Agile based project management

More Related Content

What's hot

Viewers also liked

Similar to Agile based project management

More from WGroup

Recently uploaded

Agile based project management