A Technology Business Guide To Success

A Technology Business
Guide to Success
30 Ideas You Can Use Now!

A Technology Business Guide to Success

30 Ideas You Can Use Now!
Copyright ©2010
All rights reserved. No portion of this book may be reproduced in any form without written
permission from the publisher.
SPONSORED BY
SoftServe, Inc., a leading global provider of proven high quality software development, testing
and consulting services. We are passionate and committed to bringing the best commercial
software to market for new and established independent software vendors and organizations
that use software to enable their businesses. We combine our unmatched experience with best
practices delivering innovative solutions in strategic areas of expertise including SaaS/Cloud and
Mobility. Founded in 1993, SoftServe is headquartered in Fort Myers, Florida, with an award-
winning development organization based in Ukraine and the Philippines. For more information,
please visit www.softserveinc.com.
2 A Technology Business Guide to Success: 30 Ideas You Can Use Now!

Table of Contents
Table of Contents
Introduction 5
Software Development 6
The Differences between Usability and User Experience 7
Techniques for Successful Software Product Management 10
Business Process Design using Agile Concepts 20
Managing Project Risk: What’s New? 25
Market Segments in Customer-Centric Product Development Model 29
The Importance of Software Requirements for Superior Software 34
The Role of the Software Architect in Applications and Systems Development 37
The High Costs of Building the Wrong Product 41
Business Process Improvement is a Strategic Necessity 44
Software-as-a-Service 51
Cloud Computing Reality Check 52
Are On-Demand Applications Right for Your Business? 58
Six Things for CIOs to Consider Before Moving to Cloud Computing 61
Will Project Managers Have Their Heads in the Cloud? 64
Agile 68
Agile Removes Limitations 69
Business Analysts Mitigate Agile Project Risks 73
The Marriage of Lean, Scrum and Extreme Programming (XP): How to Align Agile Across an
Organization 77
Introducing Agile Development? Move Gradually! 86
Evolving from Traditional Project Management to Agile 95
How to Scrum 102
www.executivebrief.com 3

Table of Contents
Agile Transformation Guidelines: Avoiding Pitfalls 109
Managing Customer Expectations in IT Outsourcing 114
Outsourcing is Not a Slam Dunk 119
Software Development Outsourcing: Get Control of Cultural Differences 127
Project Management 133

Five Pillars of Practical Project Management 134
Value Triple Constraint: How to Evaluate Project Value Delivered 137
Why Project Scheduling Must Not Become an Extinct Science 144
Was Deming Right About Quality Management and Project Outcomes? 149
Build Your High-Performance Virtual Team: 7 Key Steps 155
Common Project Management Hurdles and the Challenge of Change 158
How to be a Project Goal Scoring Champion 161
About ExecutiveBrief 164

Introduction
Introduction
ExecutiveBrief is an online periodical for technology managers and business leaders. We
provide quality content on software development, Agile, SaaS and Cloud, outsourcing, project
management and risk management. Our mission is to explore how to help you optimize your
resources in each of these areas.
ExecutiveBrief recognizes the power that is in information - insights and analysis on emerging
trends, best practices, and industry events — in order to fit, succeed, and compete in a fleeting
technology world. We partner with leading industry experts to produce and publish useful
information which is available free to ExecutiveBrief subscribers.
This book is a collection of 30 of the best articles we produced over the last year, chosen by
tracking our website readership statistics. Our plan is to issue a similar compilation once per
year in order to give our readers a full electronic version of the most popular articles we have
published during the preceding 12 months. Our hope is that the e-book will make its way around
and expose more executives to the benefits of our material.
Our website www.executivebrief.com has many more articles similar to the ones in this e-book,
and also white papers and short practical tips (blogs). If you haven’t done so, we encourage you
to register and receive our monthly newsletter with the best articles published. We have been
publishing since 2008, and we are constantly learning from our readers to help us grow and
improve.
If you have any comments, please e-mail us at editorial@executivebrief.com and we’ll try
incorporating your suggestions as well. If you are an industry expert and would like to contribute
to Executive Brief, please send your resume and samples of work.
Stay tuned for new exciting developments in 2011!
ExecutiveBrief Team
Software Development
SOFTWARE DEVELOPMENT

The Differences between Usability and User Experience
The Differences between Usability and User

Experience
Learn about the differences between the Usability and User Experience which are rapidly gaining
popularity but often confused or thought to be synonymous.
The rapid growth of RIA technology into the

lives of every day people just a few years ago has
carried both the usability and user experience
industries to a new high in popularity. The
success of software (particularly on the web) has
driven both of these terms into our vernacular,
and yet they are still often confused or thought
to be synonymous. This post is meant to help
those new to the field or unfamiliar with
the intricacies of design to understand the
differences between the terms.
Usability refers to the ease with which a user can accomplish his or her goals using any tool.
Coming from the field of human factors engineer, usability has been applied to software in the
fields of human computer interaction and includes many important ideas from psychology and
statistics. Usability is fundamentally qualitative but involves the heavy application of quantitative
data to identify areas of weakness and suggest improvements. The study of usability often
focuses on performing extensive tests with large groups of individuals, sometimes involving in
depth techniques like eye tracking to determine how users interact with interfaces and any areas
in which they get lost. Highly usable interfaces are often lauded for being intuitive, simple or
extremely learnable.
Somewhat in contrast, user experience

refers to the way a user perceives his or her
interaction with a system. User experience
design encompasses both interaction design
and visual design and seeks to promote an
interface that is pleasing to the user. The
study of user experience often focuses more
on the psychological impact of interacting
with the system than pure usability does,
and user experience experts will spend
their time performing both ethnographic
and psycho-graphic research to construct
Usable for certain.
their interfaces. User experience design is more qualitative than usability, though the two are not
necessarily exclusive. For instance, often times user experience experts turn their designs over to
usability experts to test and validate them in the field.
By far the easiest (and probably most over-cited, please forgive me) to distinguish these two
comes on lauded usability expert Jakob Nielsen’s homepage, useit.com. Jakob has dedicated
a lifetime to the study of usability, and his website represents a page that is extremely easy to
interact with. Everything is front and center, easily searchable, with important ideas stressed
through bold text. Yet despite its high level of usability, the lack of interesting layout, design, or
even typography makes the site rather boring and feel uninspired. I can accomplish my goals
here easily, but I probably won’t have much fun in the process.
On the flip side, let us consider interfaces which receive a high rating in user experience but
perhaps a low one in usability. A good user experience is one in which the user is pleased with
their interaction, but this says nothing about the user’s ability to achieve their goals. While these
two things are usually well aligned this is not always the case, and sometimes the most successful
interfaces are those that can make difficult systems so enjoyable that even failing to achieve
ones goals is still fun. My favorite example for this is, to the detriment of my online reputation
and popularity with a large portion of the internet, Apple. Apple does an amazing job producing
software that is fun to interact with but from a usability perspective much of it is atrocious. The
iPhone is mired in confusing interfaces requiring a high
number of clicks to achieve any goal, as anyone who has
tried to use the “Maps” app for directions while driving can
attest. If you need farther proof, just try and explain how to
use iTunes or the app store to your grandmother. It’s nearly
impossible to understand without extensive time spent
learning the interface and this is more or less the definition
of low usability. Yet Apple’s great reputation in interface
design is not entirely without merit, as their attention to
user experience is second to none. Failing on the iPhone is
more enjoyable than succeeding on a Blackberry.
Perhaps the simplest way to distinguish the two would

be to summarize them as “art” and “science”, with usability
representing science, though I caution you to use this
callous and unrefined description sparingly and certainly
not within ear shot of opinionated practitioners of either
field, as it is sure to cause a (not wholly unjustified) rant. I dare you try this while driving.
Yet the distinction is not without merit - user experience is
often far more concerned with subjective artistry, and the I take that back - please never try
emphasis on data crunching and numbers in true usability to use this while driving.

The Differences between Usability and User Experience
research is surely scientific. At the end of the day all that is really important is to understand the
distinction between the two terms and to realize the massive importance of both in the design of
good interfaces.
Credit for some of the ideas in this post goes to Timothy J. Wood, who let me listen in while he
explained the difference between usability and user experience this morning.
The article was originally published at InsideRIA
About the Author

RJ Owen is a Senior Developer at Effective UI. RJ was the lead developer on projects for Dow
Jones, Random House and the Discovery Channel and contributed to ebay Desktop and
the Adobe Video Workshop. In late 2007 RJ was featured on the Scoble show discussing RIA
development and is passionate about the way that software affects and can improve people’s
lives. He is certified as an Adobe Community expert in Flex and co-authored the O’Reilly shortcut
“Flex 3 Early Evaluator.” RJ runs a flex blog called A Better Experience and while it’s not as popular
as Rich’s, it’s still pretty good. RJ holds a degree in Physics and Computer Science, generally does
well on standardized tests, and lives in Colorado with his wife Marty.
Techniques for Successful Software Product

Management
Concrete practices that boost your organization’s software product management performance.
It’s easy to confuse the disciplines of project

manager and product manager. Simply put, the
development of the product or service falls to
the project manager, while the market success of
software and system products depends on the
skills and competence of the product manager.
This article provides an overview of software
product management and the role of a product
manager, and describes concrete practices that
can boost an organization’s software product
management and thus the success rate of
products in terms of predictability, quality, and
efficiency.
Imagine loggers in a forest. They work hard and cut tree after tree. It is a huge physical effort and
their foreman drives them hard to stay on schedule. He wants to cut a certain number of trees
per day and provides the workers with all they need to achieve this objective. Suddenly the client
shouts, “you cut down the wrong trees!” Despite all the hard work of the foreman and his team,
they did not manage to deliver the intended customer expectation. Sound familiar? Indeed, this
is what I’ve observed with many software products. Organizations are pushed to the extreme to
be ever more efficient and create products at a low cost, but when it hits the market and sales are
lower than expected or customers demand several changes during the development process,
margins are dramatically reduced from initial targets.
Successful product management means delivering the right products at the right time for the
right markets. Naturally, the success of a product depends on many factors and stakeholders.
However, it makes a big difference when a person is empowered to manage a product from
inception to market and evolution – and the same person is held accountable for the results. This
is the product manager.
At Vector Consulting Services, we have learned from experience with many clients in different
industries that success comes from anticipating and meeting the customer’s needs together
with being on time and on budget. Technical product development – such as for automotive
components, communication solutions, defense systems, or IT infrastructure – traditionally
focuses on the project perspective and operationally executing a set of given constraints within

Techniques for Successful Software Product Management
the triangle of content, budget, and time. Often, it becomes clear too late that customer needs
were different from what is built.
Project execution can be rather easily improved by means of CMMI®. Today, there are a lot
of exciting results from optimizing projects in terms of cost and cycle time [1, 2]. However,
the software product management responsibility and underlying processes remain vague. I
often see product definition, road mapping, and marketing decoupled from the engineering
project-related processes, which creates deficiencies and overheads such as heavy changes in
requirements and missed market opportunities. It is like the loggers: The project runs well, but
with the wrong results.
While an organization can embark on the general principles of product management [3], not
much specific guidance is available for software product management. This article will provide a
small introduction and tutorial on software product management.
What Is Software Product Management?

Product management is the discipline and business process governing a product from its
inception to the market or customer delivery and service in order to generate the largest possible
value to a business. A product is a deliverable that has a value and provides an experience to its
users. It can be a combination of systems, solutions, materials, and services delivered. Product
management provides leadership to activities such as portfolio management, strategy definition,
product marketing, and product development.
Often, the roles of product manager, project manager, and marketing manager are unclear in
their distinct responsibilities. To successfully define, engineer, produce, and deliver a product,
these three roles need to be clarified [3, 4, 5]. Figure 1 provides an overview of an archetypical
product life cycle and shows how different projects integrate towards an end-to-end view of the
product. It highlights the differences between managing a project and managing a product. The
project is a temporary endeavor undertaken to create a product. The project manager focuses on
delivering one specific product or release while meeting time, budget, and quality requirements.
The product manager looks to the overall market success and evolution of this product together
with its subsequent releases, related services, etc.
Figure 1: Software Product Management Spans the Entire Product Life Cycle
To clearly assign responsibilities, there should be three distinct managerial roles:

The product manager leads and manages one or several products from inception to phase-
out in order to maximize business value. They work with marketing, sales, engineering,
finance, quality, manufacturing, and installation to make the products a business success [3].
They have business responsibility beyond the single project. They determine what to make
and how to produce it, and are accountable for business success within an entire portfolio.
They approve the roadmap and content and determine what and how to innovate, and are
responsible for the entire value chain of a product following the life cycle, asking: What do we
keep, what do we evolve, and what do we stop?
The project manager determines how to best execute a project or contract. They ensure that
the specific project is executed as defined and are accountable for business and customer
success within a contract project. They manage the project plan and its execution and ask:
How do we get all of this accomplished?
The marketing manager determines how to sell a product or service in order to create a
customer experience. They are accountable for market and customer success and have
a profound understanding of customer needs, market trends, sales perspectives, and
competitors. The marketing manager communicates the value proposition to sales and
customers, drives the sales plan and execution, and asks: What markets will we address?
One might argue that in many organizations, one or several of these roles are laid out differently
and might simply be coordinating based on directions received from management. While this
has certainly been observed, such organizations often encounter interface and responsibility
battles and have a lack of ownership as a result. These three roles are necessary and need to be
empowered – and held accountable for results. This not only stimulates motivation, but also
facilitates faster and more effective decision making in a company [2, 3].
Over the years, Vector Consulting Services has investigated root causes of such insufficient
product management and its impacts on hundreds of technical products with different origins,
development paces, and sizes [1, 4]. Figure 2 provides an example of how product management
failures cause rework, scope creep, and delays. Insufficient product management typically
lacks vision, has an unclear market and business understanding, and doesn’t involve the right
stakeholders (see the left side of Figure 2). This leads to initial symptoms such as a conflict of
interest on priorities and contents and incomplete requirements. From here, it’s a vicious circle
with changes that necessitate rework, which in turn causes delays, which in turn causes scope
creep – and so on. Poor product management causes insufficient project planning, continuous
changes in the requirements and project scope, configuration problems, and defects. The obvious
(yet late) symptoms are more delays and overall customer dissatisfaction due to not keeping
commitments or not getting the product they expect (the right side of Figure 2). Being late with
a product in its market has immediate and tremendous business impacts [6, 7, 8]. In the contract
business, this often means penalties and, in practically all markets, it reduces customer loyalty
and overall sales returns.

Figure 2: The Results of Insufficient Product Management
The tangible problems can’t be fixed by pushing a button; instead, the upstream root causes need
to be fixed. It would be fatalistic to just take it for granted that requirements changes will always
cause delays or that business cases are always wrong. Rather, an empowered product manager
acting like an embedded CEO (and held accountable for results) will try to fix internal problems
and adjust to external constraints and needs – similar to a CEO who cannot simply excuse low
performance with bad circumstances. Having worked with different companies in a variety of
industries on software product management, we emphasize what we call the 4+1 best practices
to optimize product management.
4+1 Product Management Best Practices

Four software product management best practices will improve the situation, if used together.
These techniques have been found to reliably improve project performance. A “+1” practice is
added to highlight the need for personal competence growth.
1. Install an Effective Core Team

Often, different stakeholders have un-aligned agendas that make the project late and cause lots
of overhead and rework. The first thing to do is formally create a core team with the product,
marketing, project, and operations managers for each product (release) and make them fully
accountable for the success of a product. These people represent not only the major internal
stakeholders in product or solution development, but also sufficiently represent different external
perspectives. The core team leads the product development in all its different dimensions. They
typically meet once a week to discuss all open issues, risks, and relevant aspects of the product.
Decisions are taken and implemented by the respective function. I suggest announcing and
making this core team operational as early as possible in the product life cycle, but certainly
when the product or release is defined. The success factor is to give this core team a clear
mandate to own the project. I have observed that the most need for active support is in the
building of an effective core team that agrees that they have to steer the course together. Too
often, we face silo organizations in marketing, where product management and engineering
don’t work together. In many cases, this means the necessity is not only to build teams, but also
to train and coach employees and to adjust annual targets and performance management. As we
often realize, culture changes when targets are adjusted.
2. Enforce the Product Life Cycle

Like the core teams, making a standardized product life cycle mandatory for all product releases
(i.e., all engineering projects) is essential. Most companies today have such a life cycle defined,
but rarely use it as the pivotal tool to derive and implement shared and committed decisions.
Too often, requirements changes are agreed on in sales meetings without checking feasibility,
and technical decisions are made without considering business case and downstream impacts.
A useful product life cycle has to acknowledge that requirements may never be complete and
may indeed be in a continuum state. The product life cycle should guide with clear criteria (i.e.,
determining what is good enough or stable enough). This implies that it is sufficiently flexible to
handle different types of projects and constraints. This is achieved with basic tailoring techniques
and guidance as to which elements are mandatory and which should be adjusted to the specific
environment. To foster discipline and visibility, the mandatory elements of gate reviews (such
as checklists or minutes) must be explicit and auditable. To reduce overheads, I recommend
using online workflow management, which operationally embeds tools and measurements in
the product life cycle. Ease of execution with such workflow automation will facilitate reuse,
data quality, and consistency. With the current abundance of workflow management systems, I
suggest evaluating potential solutions versus your own needs to simplify the process.
3. Evaluate Needs and Requirements

Requirements must be understood and evaluated by the entire core team to ensure that
different perspectives are considered. Each single requirement must be justified to support the
business case and to allow management of changes and priorities. With our clients, we often
found requirements simply being collected, yielding lots of unnecessary features that added to
complexity – but not to customer-perceived value. In fact, almost half of all delivered features are
rarely used and do not provide any payback [1, 7]. If a product is developed on such an unjustified
basis, it is in trouble because its requirements will continuously change. A product (release) must
address a need and must have a strong business vision. This vision (i.e., what will be different
with the release of the product) must be coined into a sellable story. The story then translates to
business objectives and major requirements. Good product management first understands the

customer’s needs and business case, and then develops the necessary features. Requirements
are a contract mechanism for the project internally and often for a client externally. They must
be documented in a structured and disciplined way, allowing both technical as well as market
and business judgment. Their evaluation should specifically look to completeness, consistency,
and understandability. Ask a tester to write a test case before processing the requirement. Ask
the marketing manager to check whether he or she can sell the feature as described; this avoids
unrealistic or overly complex feature lists that don’t address real needs. Requirements should
not be overly detailed or there is a risk of paralysis by analysis; determine what is good enough
and ensure that any further insight is adequately considered. After evaluation, requirements
are approved by the core team. Only thereafter are the requirements formally allocated to the
project, and the engineering effort is spent. Requirements and business objectives must be
managed (planned, prioritized, agreed, monitored) throughout the life cycle to assure focus [7,
8]: Have a project plan that is directly linked with the requirements. Work packages within this
project plan should show the value they contribute with such links to requirements. Following
these directions allows an organization to both focus on what matters and monitor the earned
value of the project from beginning to end, as well as proactively manage risks, such as effort
being burned without creating value. Also note that your change management needs to be both
formal and disciplined, because most issues I’ve seen in troubled projects result from creeping
requirements and insufficient impact analysis. To ease change management, install traceability
from requirements upwards to the business case and downwards to test cases.
4. Assure a Dependable Portfolio

Managing release roadmaps – and their own portfolio as a mix of resources, projects, and services
– must be the focus of each product manager. Often, roadmaps are not worth the paper they are
printed on due to continuous changes that result in a lack of buy-in from sales, operations, and
service. Projects are started ad-hoc, while necessary reviews and clean-ups in portfolios rarely
happen. With moving targets, sales has no guidance on how to influence clients, and engineering
decides on its own which technologies to implement with what resources. The product manager
has to show leadership and ensure dependable plans and decisions that are effectively executed.
Dependable means that agreed milestones, contents, or quality targets are maintained as
committed unless a change is agreed on and documented. Be aware that, as a product manager,
each ad-hoc content or release change will create the perception that your portfolio is not
managed well. Apply adequate risk management techniques to make your portfolio and
commitments dependable; as you may find, projects may need more resources, suppliers could
deliver late, or technology won’t work as expected. For instance, platform components used by
several products might use resource buffers, while application development applies the time-
boxing technique. If there is a change to committed milestones or contents within the portfolio, it
must be approved first by the core team and, where necessary, by respective steering boards and
then documented and communicated with rationales.
The “+1”: Evolve Your Product Management

Just having these four software management practices distilled and processes agreed upon is not
sufficient in order to improve the product management culture. Often, I’ve seen organizations
where product managers complain about a lack of empowerment and remain in an observer
role. The truth is that they simply don’t have the right competencies to be empowered as a
mini-business owner; this leads to the wrong people in wrong positions. To achieve a true
culture change, I strongly recommend competence building for all product managers across
an organization. This means change management and closely working with product managers
to help them grow. Such individualized and focused competence management strengthens
individual product managers and helps them achieve their missions. The equation is simple:
Competence and leadership enforced from the bottom up in each project yields better products,
which grows motivation and improves the overall performance.
Our software product management framework was shaped by working with hundreds of product
managers worldwide in different industries [4, 5]. Figure 3 shows the product management
framework in a simplified format. The top shows a product life cycle as most companies today
have it formally up and running. Processes are derived from best practices and underline the
formal content of product management in an organization. The middle section of the figure
shows the typical processes that a product manager is responsible for, or is at least heavily
involved with. Finally, what is derived from these processes (shown on the bottom of the figure)
are the competency needs of an organization’s product management. While there are overlaps
across companies, focus areas differ (e.g., a software service provider has different focus areas in
this framework than an automotive supplier).
Figure 3: The Software Product Management Framework

This being done, we can get back to organizational change management and working with each
product manager to identify their own strengths and weaknesses. The competencies are used
as a basis to provide individualized training and coaching for closing gaps. With good change
management and coaching, I’ve observed a strong motivational push, and have seen (during the
competency evolution process) the product management community starting to take shape:
Incumbents had a role model (who had been actively trained); an increasing number of product
managers became interested in working more methodologically, primarily because they saw
the success of other business units and colleagues who had already started implementing the
necessary changes [4].
Product managers often ask what they can do to deliver better results. Here are 10 ways to
personally grow as a product manager:
1. Behave like an embedded CEO.

2. Drive your strategy and portfolio from market and customer value.
3. Be enthusiastic about your product.
4. Have a profound understanding of your markets, customers, and portfolio.
5. Measure your contribution on sales (top-line) and profits (bottom-line).
6. Periodically check assumptions such as business cases.
7. Take risks and manage them.
8. Foster teamwork based on Lean processes.
9. Insist on discipline and keeping commitments.
10. Be professional in communication, appearance, and behavior.
Having observed hundreds of industry projects from domains such as small software applications
and services, embedded systems to large communication and IT systems, I strongly suggest
applying the four software product management practices in parallel; they depend on each
other. Their combined use will significantly reduce delays and thus improve market performance.
These four practices are applicable in different organizations and industries. They are tangible
and can be formally introduced to projects during the launch period, thus reducing the impact
change and allowing an organization to see the growing benefits early in their projects.
The Business Value

Does better software product management mean better business performance? At Vector
Consulting Services, we have performed a root cause analysis of hundreds of products that
underperformed and found similar causes reappearing. Root causes included business cases
that were never re-evaluated, unbalanced portfolios that strangulate new products, insufficient
management of new releases and service efforts, and a lack of vision causing requirements to
continuously change. This is underlined by observations such as in [6], which indicates that the
top 20 percent of enterprises deliver 79 percent of new products on-time, while the average
enterprise delivers only 51 percent of on-time projects. The same holds true for efficiency: We
found that with a requirements change rate beyond 20 percent in a project, productivity falls, and
as such, business performance [1].
Improved product management has a profound positive impact on overall business. For instance,
strengthening the product management role at Alcatel-Lucent showed that duration (time to
market), schedule adherence, and handover quality all improved in a sustainable way. We have
been working with hundreds of product managers and achieved a 20 percent per year reduction
of delays [1, 4]. Explanatory factors for this positive impact of product management include
leadership and teamwork, managing risks and uncertainty, mastering stakeholder needs, and
accountability towards agreed business objectives – managed by one empowered person across
the product life cycle.
Conclusions
Using the 4+1 method means more ownership, leadership, and motivation in product
development teams and at their interfaces. Each of the practices can be applied within a single
product line if a company is not yet prepared to introduce them across all product lines. The
practices and overall product management framework can be gradually introduced to product
lines or business units, thus reducing the change impact. Practitioners in engineering, product
management, and marketing accept these practices because they yield concrete performance
improvement and stimulate empowered project teams.
Growing an organization’s product management discipline requires good change management

to achieve a culture where these practices are used and implemented by teams across the
organization, supported by their management, and communicated openly to resolve conflicts.
For improved software production and market success, product management is here to stay. It is
not a proxy to arbitrate a variety of conflicting interests, but rather a key business role in an entire
company that is empowered to act as a business owner. It provides the basis for success or failure
in the product’s development. Or, using our initial analogy: If you do not know which direction
to take in cutting the trees, don’t simply start just to show progress. Real progress is what creates
a lasting user experience, and this is defined from a product perspective – not ad-hoc during
project work in a shouting contest.
Acknowledgement
This article is based on evolving the product manager competence in different companies

worldwide. The 4+1 best practices had been fine-tuned during many discussions at the
International Workshop on Software Product Management (IWSPM) series.
References
1. Ebert, Christof, and Reiner Dumke. Software Measurement. New York: Springer, 2007.
2. Reifer, Donald J. “Profiles of Level 5 CMMI Organizations.”Jan. 2007.
3. Gorchels, Linda. The Product Manager’s Handbook: The Complete Product Management
Resource. 3rd ed. New York: McGraw-Hill, 2006.
4. Ebert, Christof. “The Impacts of Software Product Management.” The Journal of Systems and
Software. Vol. 80, Issue 6: 850-861, June 2007.
5. IWSPM. Proc. from the International Workshops on Software Product Management. 12 Sept.
2006, Minneapolis, and 9 Sept. 2008, Barcelona, Spain.
6. Cooper, Roger G., et al. “Benchmarking Best NPD Practices.” Research-Technology
Management. Part I: Jan. 2004: 31; Part II: May 2004: 43; Part III: Nov. 2004: 43.
7. Davis, Alan Mark. Just Enough Requirements Management. New York: Dorset House, 2005.
8. Karlsson, Lena, et al. Challenges in Market-Driven Requirements Engineering – An Industrial
Interview Study. Proc. of 8th International Workshop on Requirements Engineering:
Foundations for Software Quality. Essen, Germany: 37-49. 9-10 Sept. 2002 .
The article first appeared in CrossTalk, Jan 2009
About the Author

Christof Ebert, Ph.D., is managing director and partner at Vector Consulting Services. He is helping
clients worldwide to improve technical product development and to manage organizational
changes. Prior to working at Vector, he held engineering and management positions for more
than a decade in telecommunication, IT, and transportation. As a business consultant, author
of several books, lecturer at the University of Stuttgart, and public speaker, he has influenced
numerous companies with his results-driven contributions. You can contact Christof at christof.
ebert@vector-consulting.de
Business Process Design using Agile Concepts

Business process design takes a page from the software development playbook. Discover new
strategies for better business process design using agile concepts.
Have you heard the news?
“60% of all software development projects fail to

meet their goals.”
Of course you’ve heard this. EVERYONE has

heard this nugget of wisdom. It starts off
presentations, it’s used in consulting pitches,
software integrators put it in their marketing
materials, and IT departments promise it won’t
happen to them (or you). Here’s the problem: it’s
probably wrong. I believe that, in fact, closer to
80% of enterprise software development projects fail to meet goals. The key is — it is a specific
type of software project that nearly always fails. The type of development project that nearly
always fails is the “old school” waterfall-type project. The kind that starts out with requirements
crafted in excruciating detail, progresses to multiple layers of sign-off, is developed in several
phases — each with their own system, unit, and user acceptance testing — and eventually
finishes with a final result that doesn’t fit the needs of a business that has long since moved on.
Over the years I’ve seen software that was released that no longer fits an evolved business model,
software that missed huge, key requirements, and software that was released just in time for an
acquisition that changed the entire business environment.
Whew. I’m frustrated just thinking about it. Luckily, the software development industry (mostly)
figured out that this was a problem quite while ago. Most successful projects today — especially
externally facing consumer projects — follow a very different trajectory than the development
projects of ten or even five years ago, emphasizing tighter contact with the customer, faster
development cycles, and the testing of smaller chunks of code.
So what does this have to do with business process design?

Unfortunately, many business process redesign efforts make those old-school enterprise software
projects look like Olympic champions by comparison. Unlike their software development
counterparts, most practitioners of “process redesign” have not been so eager to bring their
methods into the 21st century. In fact, while software design is largely light-years beyond where
it was in the early 1990s, process design — for the most part — has changed very little. The
practices learned many years ago a largely still followed:

1. Document the old process in mind-numbing detail (about two weeks’ worth of time)
2. Identify the issues in the old process (a week here)
3. Design phases for a new process (another week)
4. Design the details for the new process (easily four weeks)
5. Implement the whole thing as one giant project (I don’t even want to guess...)
6. Hope it works (and that the design is still relevant after so much time has passed)
And surprise, like the outmoded techniques for software design, the process design projects
conducted in this manner also have an extremely high “failed to achieve results” rate — even
worse than for IT projects in my experience. I speak from experience — this is exactly the way we
used to perform process redesign work in the past. Redesigning a process using this “technique”
was tedious and frustrating, both for us and for our clients. And, it was tough to achieve the
desired result.
But it doesn’t have to be this way.
Process redesign projects don’t have to be lumbering, slow, painful exercises that rarely succeed
in achieving their goals. By learning the hard-won lessons of software developers, you can
dramatically increase your chances for success in your process redesign project.
When software development moved past traditional waterfall-style development, a new way of
thinking emerged called “Agile Development.” Agile development stresses speed over perfection,
rapid development of small bits of functionality, and testing of all deployed code. How can this be
used for business process improvement? Here are three of the main “agile” concepts and how you
can use them to improve processes more rapidly and with a much higher success rate:
Lesson #1: Minimum Viable Process (MVP)

One of my favorite phrases is “the perfect is the enemy of the good,” and nowhere is this more
true in the design of business processes. In the past, businesses undergoing process redesign —
whether they called it TQM, BPR, or Six Sigma — all made a similar mistake. They took far too long
to develop the process, hoping for a “perfect” final design that met all objectives and avoided
all constraints. As someone who has fallen prey to this seductive path myself, I can tell you with
100% certainty that there is no “perfect process” waiting around the corner, there is no “magic
bullet,” there is no single “correct solution.” The process that is actually deployed and is actually in
use is almost always better than that “perfect” process that exists only on a Visio diagram hanging
on the wall. Business needs and goals change so quickly these days that you simply cannot afford
to spend months designing the ultimate business process. By taking an extended period of time
to develop our business processes, we risk a final product that was “perfect” for the situation that
existed several months ago — but useless in today’s environment.
So how do we reconcile the need to improve processes with the need to move quickly and get
something that improves the situation up and running? One solution is called the “minimum
viable process” or MVP. The concept is simple: design the simplest, most basic process that will get
the job done and iterate from there. Ok... So what does THAT mean? It means that you dispose
of just about everything that isn’t directly related to delivering the output of the process until
you can prove that without the pieces that are left, the process simply cannot function. It means
that you design the process without the multiple re-work, validation, approval, and wait state
loops that dominate most processes today. Treat each process checkpoint or approval state as
a design failure — a process step that exists only because the process itself is inherently flawed
in even needing a checkpoint — and try to design that step away. Obviously you won’t be able
to eliminate every single check & balance step in your process, but minimize them and see what
happens. The key with the MVP design is that you need to get a new process out, up, and running
as quickly as possible to test its performance in the real world. Those super-complex, “perfect”
processes will need to reach the real-world stage at some point — wouldn’t you rather have spent
two-thirds less time in process design when you find out that your process has major flaws that
must be corrected? Use the MVP as your initial test platform to challenge your assumptions and
ideas about the new way of doing work. Then, use the next concept — Continuous Deployment
— to make the process better fit the goals of the business.
Lesson #2: Continuous Development & Deployment

ANY process that you design — whether you spend days, weeks, or months building it — will
have problems. You can count on it. I’ve designed and implemented many new processes over
the past 15 or so years, and I have yet to see a single process that, once “in the wild,” didn’t have
to change to some degree. With this being the situation, the key to a successful process design
implementation is the pace at which you are able to effectively change the process design in
response to the issues that you identify. Often, organizations take an “implement once and forget
it” approach and unfortunately this results in an overall poor redesign result (part of that 60%).
You have to find the process flaws and fix them quickly.
So how do you remedy this situation, recognize issues with processes and make changes that will
better meet the design goals? The best practice for this is called “continuous deployment” and has
grown in popularity in the software development community over the past few years. Here’s how
it works in the software world:
1. you work closely with the “customer” to understand and build the software
2. you release the software in little “chunks” of functionality
3. you observe and fix
4. you release again
This all happens very quickly. In fact, one of the leading advocates of continuous deployment,

Eric Ries, talks about how his company would deploy commercial software to the customer
base multiple times per day. He stated that if each engineer didn’t deploy at least every few
days, it meant that something was wrong. You can make the same continuous development &
deployment principle work for you when redesigning business processes. Adopt the philosophy
that every day during the design cycle, something, anything, must be “shipped.” It could be a new
form for ordering, a prototype of an online database for tracking customer data, or a change to
your CRM tool. The key is that you release constantly and learn from what happens. Think small
frequent changes, not big delayed changes.
By now you might be thinking “Wait — we can’t do that. What if we get it wrong? We need to
perform testing/cost-benefit-analysis/executive review/financial review/legal approval/(insert
committee here) review before we do anything. We could hurt the business.” I don’t believe that
for a second. The potential for having a small “release” of a business process change — one that
you monitor very closely to observe the results — damaging the business irreparably before
you see the problem and release a process fix is very low. In fact, I would argue that these small
process releases are much easier to monitor and problems are far easier to detect that when you
perform one massive release at the end of a process redesign. World-leading design firm IDEO
calls the concept of converting risk into smaller, manageable pieces “risk chunking” and uses it to
ensure that their new product designs aren’t an “all or nothing” proposition. You want to see risky?
Forklift in a massive process implementation after eight or ten weeks of design work and try to
identify the issues (or benefits) that are associated with what you just did. Now THAT’S risky!
Of course, if you release a new process or a process change and then ignore it and move on to the
next challenge, you’ve missed the point. When performing continuous deployment of process,
you must monitor the results. Did it work? Did it cause unintended consequences? The way to tell
is through another software technique called “A/B testing.”
Lesson #3: A/B Process Testing

You’ve created the smallest, leanest process possible, you’ve implemented it using continuous
techniques, now what? Now you need to test the results. Often, process implementations are
treated almost like a bullet to the head — one shot and it’s over. The software world has taught
us nothing if not the need for constant review of the effectiveness of each “release.” Imagine
software that was released, had bugs, and was never reviewed or fixed. How likely would you be
to call that software a success or to recommend it to a friend or colleague? In the software world
of agile development, a technique called “A/B testing” or “split testing” is used to determine the
implications of a recent release.
Here’s how A/B testing works: you are doing continuous, small deployments so each piece of
functionality is relatively easy to understand in terms of its implication to the users. When you
deploy this small functionality change (the “A” functionality), you deploy it to a sub-set of the
users and compare to the users who are still using the old functionality (the “B” functionality).
Think of it like a small, rapid beta test. This can have huge, beneficial implications for software
— think of what would happen if you deployed a new “Buy Now” button to a website but
accidentally colored the button the same as the page background. You now have, as Eric Ries
says, “a hobby, not a business model.” Obviously, you would prefer to detect an issue such as this
sooner, rather than later.
Use the A/B testing concept for your business process changes. Instead of deploying a changed
form, website, or process to the entire set of “users,” deploy to a smaller set of test users and
compare the differences. Did the new process perform the way you expected? If so, deploy
the change to the rest of the process users. If not, go back, re-develop that part of the process
and re-deploy. Continuous development and A/B testing are a tightly linked loop of design,
development, deployment, testing, and re-development. Just remember that A/B testing without
continuous deployment means that mistakes will be out in the wild much longer than they
should and continuous deployment without A/B testing means that issues may go unnoticed for
far too long.
We need to break out of that old cycle of developing monolithic processes only to have them fail
to produce the results we anticipated. In an environment where every dollar counts more than
ever, we just cannot afford a 60% plus failure rate in process redesign. It not only costs us time
and money, but also credibility with employees. Use the lessons from software development and
build lean, minimum viable processes, deploy them quickly and continuously, and test the results
against the old process. Everything you implement won’t be a success, but when a mistake does
occur, you will find it quickly and be able to rapidly make the changes necessary to succeed when
you implement the next time around.
About the Author

Kevin M. Smith is a co-founder and managing partner at NextWave Performance LLC. Prior to
joining NextWave Performance, Kevin held the position of Vice President at Retreon Inc. where he
was responsible for development of process and program management technology and delivery
of process management and improvement professional services.
As a Senior Director at Qwest Communications, he led both the Systems Strategy and the
Engineering Program Management teams for the National Networks organization. He
spearheaded the deployment of new technologies programs and developed innovative web
tools used by the corporation to manage as many as 15,000 concurrent projects for more
than 6,000 users. A “Six Sigma Black Belt,” Kevin also led corporate process management and
improvement initiatives at LCI International and MCI, and served with Booz, Allen Hamilton as a
consultant in their Process Improvement practice.
Kevin holds a B.S. in Finance, as well as an M.B.A. in Process Management, both from the
University of Maryland, College Park.

Managing Project Risk: What’s New?

Plenty. Learn the road to better project risk management through principles, process, people and
persistence.
Humans have been undertaking projects for

millennia, with more or less formality, and with
greater or lesser degrees of success. We have
also recognised the existence of risk for about
the same period of time, understanding that
things don’t always go according to plan for a
range of reasons. In relatively recent times these
two phenomena have coalesced into the formal
discipline called project risk management,
offering a structured framework for identifying
and managing risk within the context of
projects. Given the prevalence and importance of the subject, we might expect that project
risk management would be fully mature by now, only needing occasional minor tweaks and
modifications to enhance its efficiency and performance. Surely there is nothing new to be said
about managing risk in projects?
While it is true that there is wide consensus on project risk management basics, the continued
failure of projects to deliver consistent benefits suggests that the problem of risk in projects
has not been completely solved. Clearly there must be some mismatch between project risk
management theory and practice, or perhaps there are new aspects to be discovered and
implemented, otherwise all project risks would be managed effectively and most projects would
succeed.
So what could possibly remain to be discovered about this venerable topic? Here are some
suggestions for how we might do things differently and better, under four headings:
1. Principles 3. People
2. Process 4. Persistence
Problems with principles

There are two potential shortfalls in the way most project teams understand the concept of risk.
It is common for the scope of project risk management processes to be focused on managing
possible future events which might pose threats to project cost and schedule. While these are
undoubtedly important, they are by no means the full story.
The broad proto-definition of risk as “uncertainty that matters” encompasses the idea that some
risks might be positive, with potential upside impacts, mattering because they could enhance
performance, save time or money, or increase value. And risks to objectives other than cost
and schedule are also important and must be managed proactively. This leads to the use of an
integrated project risk process to manage both threats and opportunities alongside each other.
This is more than a theoretical nicety: it maximises a project’s chances of success by intentionally
seeking out potential upsides and capturing as many as possible, as well as finding and avoiding
downsides.
Another conceptual limitation which is common in the understanding of project risk is to think
only about detailed events or conditions within the project when considering risk. This ignores
the fact that the project itself poses a risk to the organisation at a higher level, perhaps within
a programme or portfolio, or perhaps in terms of delivering strategic value. The distinction
between “overall project risk” and “individual project risks” is important, leading to a recognition
that risk exists at various levels reflecting the context of the project. It is therefore necessary to
manage overall project risk (risk of the project) as well as addressing individual risk events and
conditions (risks in the project). This higher level connection is often missing in the way project
risk management is understood or implemented, limiting the value that the project risk process
can deliver. Setting project risk management in the context of an integrated Enterprise Risk
Management (ERM) approach can remedy this lack.
Problems with process

The project risk process as implemented by many organisations is often flawed in a couple of
important respects. The most significant of these is a failure to turn analysis into action, with Risk
Registers and risk reports being produced and filed, but with these having little or no effect on
how the project is actually undertaken. The absence of a formal process step to “Implement Risk
Responses” reinforces this failing. It is also important to make a clear link between the project
plan and risk responses that have been agreed and authorised. Risk responses need to be treated
in the same way as all other project tasks, with an agreed owner, a budget and timeline, included
in the project plan, reported on and reviewed. If risk responses are seen as “optional extras” they
may not receive the degree of attention they deserve.
A second equally vital omission is the lack of a “post-project review” step in most risk processes.
This is linked to the wider malaise of failure to identify lessons to be learned at the end of
each project, denying the organisation the chance to learn from its experience and improve
performance on future projects. There are many risk-related lessons to be learned in each project,
and the inclusion of a formal “Post-project Risk Review” will help to capture these, either as part
of a more generic project meeting or as a separate event. Such lessons include identifying which
threats and opportunities arise frequently on typical projects, finding which risk responses
work and which do not, and understanding the level of effort typically required to manage risk

effectively.
Problems with people

It is common for project risk management to be viewed as a collection of tools and techniques
supporting a structured system or a process, with a range of standard reports and outputs that
feed into project meetings and reviews. This perspective often takes no account of the human
aspects of managing risk. Risk is managed by people, not by machines, computers, robots,
processes or techniques. As a result we need to recognise the influence of human psychology on
the risk process, particularly in the way risk attitudes affect judgement and behaviour. There are
many sources of bias, both outward and hidden, affecting individuals and groups, and these need
to be understood and managed proactively where possible.
The use of approaches based on emotional literacy to address the human behavioural aspects
of managing risk in projects is in its infancy. However some good progress has been made in
this area, laying out the main principles and boundaries of the topic and developing practical
methods for understanding and managing risk attitude. Without taking this into account,
the project risk management process as typically implemented is fatally flawed, relying on
judgements made by people who are subject to a wide range of unseen influences, and whose
perceptions may be unreliable with unforeseeable consequences.
Problems with persistence

Even where a project team has a correct concept of risk that includes opportunity and addresses
the wider context, and if they ensure that risk responses are implemented effectively and
risk-related lessons are learned at the end of their project, and if they take steps to address
risk attitudes proactively – it is still possible for the risk process to fail! This is because the risk
challenge is dynamic, constantly changing and developing throughout the project. As a result,
project risk management must be an iterative process, requiring ongoing commitment and
action from the project team. Without such persistence, project risk exposure will get out of
control, the project risk process will become ineffective and the project will have increasing
difficulty in reaching its goals.
Insights from the new approach of “risk energetics” suggest that there are key points in the
risk process where the energy dedicated by the project team to managing risk can decay or be
dampened. A range of internal and external Critical Success Factors (CSFs) can be deployed to
raise and maintain energy levels within the risk process, seeking to promote positive energy and
counter energy losses. Internal CSFs within the control of the project include good risk process
design, expert facilitation, and the availability of the required risk resources. Equally important
are external CSFs beyond the project, such as the availability of appropriate infrastructure, a
supportive risk-aware organisational culture, and visible senior management support.
So perhaps there is still something new to be said about managing risk in projects. Despite our
long history in attempting to foresee the future of our projects and address risk proactively, we
might do better by extending our concept of risk, addressing weak spots in the risk process,
dealing with risk attitudes of both individuals and groups, and taking steps to maintain energy
levels for risk management throughout the project. These simple and practical steps offer
achievable ways to enhance the effectiveness of project risk management, and might even help
us to change the course of future history.
Note: All of these issues are addressed in the book “Managing Risk in Projects” by David Hillson,
published in August 2009 by Gower (ISBN 978-0-566-08867-4) as part of the Fundamentals in
Project Management series.
About the Author

Dr David Hillson, PMP FRSA HonFAPM FIRM FCMI, is internationally recognized as a leading
thinker and practitioner in risk management. He is Director of Risk Doctor & Partners (http://
www.riskdoctor.com), and has worked in over 40 countries. He is a popular conference speaker
and award-winning author on risk, with six books on the topic. David is an active member of
the Project Management Institute (PMI) and was a founder member of its Risk Management
Specific Interest Group. He received the PMI Distinguished Contribution Award for his work in
developing risk management over many years. Since 1998 he has been a core author for the risk
chapter of the PMBOK Guide®, and is a core author for the PMI Practice Standard for Project Risk
Management. David can be contacted at david@risk-doctor.com.

Market Segments in Customer-Centric Product Development Model
Market Segments in Customer-Centric Product

Development Model
A product development expert shares his model for describing the market and market segments which
emphasizes the critical customer-centric perspective that product managers need to have.
A market can be thought of as the collection of

contexts in which you might sell your product.
You can split your market into a set of market
segments. Each of those segments represents
a group of customers, each of whom shares a
set of problems for which they would pay for
solutions.
Customer-Centric Market Model

I’ve been developing a model for describing
markets that emphasizes the critical customer-centric perspective that product managers need to
have. This article is a first draft of that model – I’m sharing it here in hopes of getting feedback to
improve the model and my approach for communicating it.
Key goals of the model:

Provide a framework that helps product managers make decisions about products.
Establish an outside-in bias that encourages product managers to think first about customers
and second about implementation.
Encourage teams to design products that solve real problems that people will pay to solve.
Support both Agile and Waterfall
development processes.
A Model for Markets, Segments,

Customers, and Problems
A market can be thought of as the
collection of contexts in which you might
sell your product. You can split your market
into a set of market segments. Each of
those segments represents a group of
customers, each of whom shares a set of
problems for which they would pay for solutions.
Markets and Market Segments

Market segments are traditionally defined based on
aggregate data that makes it easy to operationally address
groups of customers. Business-to-business (B2B) and
business-to-consumer (B2C) markets are typically divided
using the same approach, with a few data sources that are
uniquely relevant for each type of company-to-customer
relationship.
Larger view of market segmentation approaches
Business-To-Business (B2B)
When defining market segments for B2B products, your customers are companies. Groups of
companies are defined, and organizational structures are built around those segmentation
models. Different factors and combinations of factors are used to define the different market
segments. Common B2B segmentation factors include:
NAICS Industry Definitions – A standard taxonomy for defining the different businesses in
which your customers engage.
Demographic Data – For companies, this can be number of employees, annual revenue,
corporate structure, or other characterizing metrics that are relevant to your product.
Transaction History – The history of purchases by the company. Absolute magnitude,
frequency, and recency of purchases can all be used.
Geography – Where a particular company is located. While not always correlating with

variation in companies, it may serve as an effective way to “split the work” for internal
organization – such as geographic sales teams. This type of segmentation can also help when
business rules or policies vary by geographic region – such as tax, policy, and other legal
variations that apply either to your company or your customer.
Business-To-Consumer (B2C)
Defining market segments for B2C products typically uses the same approach, with slightly
different factors for consideration. Common B2C segmentation factors include:
Demographic Data – For consumers, this can be household income, age, or other easily
measured and aggregated characteristics.
Transaction History – As with B2B segmentation, the history of purchases by the consumer is
considered. Frequency (loyalty), recency, and absolute magnitude (lifetime customer value) of
purchases are all usable.
Geography – Geography can be used for B2C segmentation in the same way that it is used for
B2B products. A designated market area (DMA) represents a region of customers that would
receive the same broadcast messages, and companies sometimes organize their customers
by DMA. Third party companies also provide geographic segmentation based on patterns of
similar demographic data that can be statistically associated with a given geography.
Behavioral Data – As an ecommerce company, you can measure and study the specific user
actions of customers on your website, correlate those behaviors with transactional actions,
and define groups of customers that “behave the same way” in order to customize their
website experience, offer targeted promotions, and otherwise organize engagement and
reporting.
Psychographic Data – Customers that consider purchasing your product for similar reasons;
customers who have similar backgrounds, experiences, and perspectives; and customers that
share user goals are commonly identified as personas. These personas are archetypes that
represent groups of customers. These groupings can be used to segment your market.
Customers
The term customer is ambiguously applied to
both buyers and users, and is only accurate
when it represents someone who is both the
purchaser and the end-user of your product. You
should explicitly think about your customers as
buyer personas and user personas.
Buyer personas compare products based on

their suitability to solve the problems that
the buyer perceives as valuable. User personas value

products based on how effectively the products
solve their real problems. This is the most important
distinction between buyers and users, while both are
focused on value, only the end users will realize the
value directly.
Market research should be focused on developing

personas that represent homogeneous groups of
customers, so that you can focus on the problems that
each group distinctly faces.
Problems
Problems to be solved for the groups of customers
that make up your market segments are what define
a market. Kano analysis provides you with the tools to
classify these problems, allowing you to make informed
decisions about which problems to focus on in your
product roadmap.
Kano analysis problem classification
Kano analysis, as originally defined, classifies products in

terms of the features or capabilities they provide. The naming
originally used by professor Kano (as translated) is slightly
different than the
terms used above.
The change in
terminology here
provides more clarity,
particularly when applying Kano analysis from a market-
perspective (outside-in) versus a feature-perspective
(inside-out).
As a market-driven product manager, you should tweak

the language of Kano into classification of problems
and solutions, because customers value solutions, not
features. All of the techniques of Kano analysis apply,
the nuance of this approach is to refocus on problems
(outside-in) not features (inside-out).
Use Kano analysis to identify each problem faced by

customers in your market as being in one of the following four classifications:
Delighter – A solution to this problem will delight your customers. As markets change over
time, customers lose their sense of delight, and come to expect solutions to previously solved
problems.
Must Be – This problem must be solved by your product, or your prospective customer will
refuse to buy or recommend it.
More Is Better – This is the classic shades of grey problem, in contrast to the black and white
nature of a must be problem. Solving part of this problem is good, solving more of it is
better. The easiest way to think of this problem is that solutions are partial solutions, and the
greater the portion of this problem your product solves, the more satisfied your prospective
customers will be with your product.
Indifferent – This is a problem for which your customers are indifferent to the solution. Buyer
decisions about purchasing your product (versus the competition) are not affected by how
capably this problem is solved. Users will not judge your product’s effectiveness based on
how well it solves this problem.
Conclusion / Request for Feedback

This view of the market as an organization of problems that are shared by groups of customers
allows you to:
Gain more insights from competitive analysis.

Prioritize the content of each release to grow (revenue or profits or market share) faster.
Design solutions that particular groups of customers will love.
Visit Scott Sehlhorst’s blog at http://tynerblain.com/blog/
The Importance of Software Requirements for

Superior Software
Do you really need to pay attention to software requirements before you start coding? Read on to
discover requirements lessons and best practices to help you ensure software success.
Have you ever been involved in a home or

office building project? Did you end up with
what you wanted? If so, it’s undoubtedly
because you stayed involved and because,
through the architect’s drawings, you had a
way to communicate your requirements. The
comparison of building a house to building a
software system is one you’ve undoubtedly
heard before. Nonetheless, the comparison is
extremely useful, and it allows us to draw some
crucial lessons.
Lesson one: You may have expressed your initial ideas in words, but the architect turned the
words into drawings. Those drawings helped you ‘see’ what the finished product would be like.
Lesson two: The drawings you and the architect worked with were presented in your terms, not
the electrician’s or the plumber’s. You could understand them.
Lesson three: You, the one paying the bills, had the opportunity to be involved and make
changes throughout the life of the building effort.
Lesson four: The requirements, the original drawings that you and the architect worked through,
drove the rest of the project. They produced electrical specs, plastering specs, and so forth. If the
assumptions in those drawings changed, the changes rippled through.
Just as in building a house, a good requirements process must have a way to help the business
owners extract, discover, and capture what they want in their own terms. A good software
requirements process must have a way to communicate unambiguous requirements to the
developers (the plumber, the electrician). And a good software requirements process must have
a way to accommodate and even encourage change throughout the life of the project (you, the
owner, are included in the process all along the way).
If your software requirements process doesn’t address these lessons, it won’t succeed.

The Importance of Software Requirements for Superior Software
Software Requirements Gathering Needs Both Words and Pictures

Most business sponsors are used to expressing themselves in words, and it is important to
capture their initial goals and objectives in a medium they’re comfortable with. In addition, text
statements are a good way to capture operational requirements such as the number of users that
must be supported, or the necessary levels of security. But what about process (or functional)
requirements? There are situations where it might take several pages to describe the process
of, say, taking an order. In this case, a visual approach to understanding a business process
flow seems preferable to a written one. The solution is to find a way to marry the benefits of
text requirements and requirements management with visual models. Software requirements
gathering needs to address visual and text requirements, and both kinds of requirements must
be tracked and managed.
Software Requirements Must Be Gathered and Presented in Business Terms

For those software requirements that would benefit from a visual approach, you will need to
find models that speaks in business terms, not IT terms. Many business owners are impatient
with entity relationship models and even more so with class models. These models may provide
the information IT needs, but may not be particularly understandable or useful to the business
side of the house. As others have noticed, the real world of business and the technical world of
computers are inhabited by two different kinds of people. Each has its own culture and language.
Business Owners Must Be Responsible for Requirements throughout the

Life Cycle
According to research done by the Standish Group the top reason for project failure is “lack
of user input.” At least some of those project failures included JAD sessions to collect user
information. They may have even had the users themselves write the requirements. Shouldn’t
that have been enough? Apparently not. As one business user said, “We’ve written requirements
documents, but developers can ignore written instructions as well as verbal. What we need is
someone to make sure each requirement is implemented as written.”
Well, who should that someone be? I believe that it’s the business owner him/herself. But if
your requirements are ‘thrown over the wall’ to development, that won’t be possible. Do you
really want to abdicate that responsibility? If not, you need a way to keep your finger in the pie
throughout the life cycle.
Requirements Are Central to the Entire System Life Cycle

How many legacy systems are out there with unknown business rules buried in the code? How
many systems are we currently building without good documentation? Why can’t we find a
way to ensure that business people not only specify the software requirements, but also have
a mechanism to understand what the system when it’s built will actually do? If you build good
requirements models, they can lay the basis for the activities of many groups down the road,
including user documentation, project manager, user acceptance testing, and the maintenance
team.
A New Requirements Process

Question: “What most often dooms IT projects?”
Answer (from a Chief Technology Officer quoted in Software Magazine): “First, we don’t know
how to talk about requirements in any precise way, which is a matter of the business people
not understanding what we need – and IT doesn’t clarify this very well, either. Specifying
requirements is a failure on both the part of the business and IT departments. Users have trouble
expressing their needs and desires in a way that the technologist can understand. There must be
someone in the middle to interpret what the user is saying and translate it to IT.”
Let’s return to the house analogy. When you embark on a building project it’s you, the owner, who
has the vision of what you want and the money to pay for what it will cost. In all but the simplest
cases, however, you turn to an architect for help. By using an architect you are getting the
“someone in the middle” referred to above. That someone should have experience, should be able
to model the solution in terms that you understand, and should be able to interpret and translate
that to the technicians. Unless you, the business owner, have lots of time and lots of experience,
you will need an outside “someone in the middle” for your application development projects.
Conclusion
Discovering, documenting and maintaining good requirements is the most crucial activity of
the entire development life cycle. Don’t fall into the ‘why aren’t we coding yet’ trap, or allow your
developers to convince you that they can build a good solution with little guidance from the
business. Spending the time and the effort up front means a better solution in the long run.
This paper is an excerpt from a more extensive white paper. For more on this and other
requirements topics, visit our web site at www.requirementsfirst.com

The Role of the Software Architect in Applications and Systems Development
The Role of the Software Architect in

Applications and Systems Development
How do software architects shape your applications and systems development? Learn the insights
from a seasoned project management expert.
In the early days of software development

little thought was given to how the software
applications and systems we built were
architected. There were several reasons for this:
firstly, software development being new, the
concept hadn’t been thought of, and secondly
we didn’t realize how important architecture
was to the cost of maintaining our applications
and systems. Upon sober reflection, we probably
should have foreseen the need for planned
architecture and architects because building software isn’t radically different from building any
other structure, for example buildings and bridges. We can’t go back and undo the damage done
by the lack of foresight that led to badly architected applications and systems but as project
managers we can avoid making this mistake in our next software development project.
Today most organizations whose core competencies include software development recognize
the importance of architecture to their business and have satisfied this need by creating the
role of architect and making this person responsible for the architecture of all the software
applications and systems they develop. Even organizations whose core competencies don’t
include software development, but who have invested heavily in IT, have created this role. These
people may be referred to as the Chief Architect, Head Architect, or Strategic Architect. Wikipedia
identifies 3 different categories of architect depending on the scope of their responsibilities: the
enterprise architect who is responsible for all an organization’s applications and systems, the
solution architect who is responsible for the architecture of a system comprised of one or more
applications and hardware platforms, and the application architect whose responsibility is limited
to one application. The category and number of architects will usually be constrained by the size
of the organization and the number of applications and systems it supports. Regardless of what
the organization you work for calls them, the software architect has a key role to play on your
software project.
Your job as project manager of a software development project, where a software architect
is in place, is to ensure that their work is properly defined and organized so that your project
receives maximum benefit from their expertise. If the organization does not have an architect
in place you will have to identify someone on your team to fill that role. What is not acceptable
is to plan the project without any acknowledgment of the need or importance of the architect.
This role requires as much knowledge of the system components as possible, including software
and hardware knowledge. It also requires deep technical knowledge of the technology being
used, both hardware and software and strong analytical skills. The person (other than a software
architect) who most probably possesses a skill set similar to this one, is a business or systems
analyst. Depending upon the size and complexity of the existing system, and your project,
existing skill sets may not be sufficient to meet your project’s needs. There are ample training
opportunities available so pick one that most closely suits your needs and have your candidate
attend. If your project has adequate budget to pay for the training, fine. If not, keep in mind
that the skill set acquired by the trainee will be available to the organization after your project is
completed and your project should not have to bear the full cost of the training.
Now that you have a qualified software architect engaged for your project, you need to plan that
person’s tasks to take maximum advantage of their skills. I recommend engaging the architect
as early on in the project as possible so that they can influence the definition of the application
or system being developed. The team that defines the business requirements to your project will
be from the business side of the organization and have deep knowledge of how the business
runs but little knowledge of the existing systems and technical features of the hardware and
software that will deliver the solution. Having a software architect available during requirements
gathering exercises will help you define requirements that leverage existing system and solution
platform strengths and avoid weaknesses. Leaving their input till a later phase exposes your
project to the risk of re-engineering the solution to fit existing architecture or avoid solution
weaknesses, after the fact. Involve the software architect in requirements gathering exercises as
a consultant or SME (subject matter expert) who can point out risks in defining requirements and
offer alternative solutions. The key deliverable your architect is responsible for is the architectural
drawing. This is not actually a drawing but a mix of drawings and text. The drawings will
represent the various components of the system and their relationship to one another. The text
will describe data elements, relations between various architectural elements, and any standards
designers must adhere to. The drawing may be a new one to represent a new system, or it may
be an update of an existing drawing to reflect the changes to an existing system made by your
project. The development of the architectural drawing is the first design activity in your project
schedule. The drawing is used in the same fashion that engineering staff and skilled craftsmen
use an architectural drawing of a building or bridge.
Analysts and programmers will use the Business Requirements Document (BRD) to tell them
what features and functions to design and the architectural drawing to tell them how their
software must fit together with other software in the system, any constraints the system
places on their design, standards the new software must meet, and what critical data elements
look like. The information in this drawing will depend on the solution chosen, the hardware
chosen, the existing system and the complexity of the project. For example, projects using an
Object Oriented solution will have 4 layers: a user interface layer (the layer the user sees), an

The Role of the Software Architect in Applications and Systems Development
application layer (where the work is done), a domain layer (where business logic is applied), and
an infrastructure layer (for logging messaging, etc.). Other solutions may call for more or fewer
layers. Software development projects which rely on a relational database to store and retrieve
large volumes of data will have a database architect who is responsible for the design of the
database. The database architect should be a member of your project team and their design
should be coordinated with the system architecture so that the data elements in the architectural
drawing are defined the same way as they are in the database’s data dictionary. Database design
is critical to system performance. Poor database design, or database design which does not
support the applications using it, will deliver a system with poor performance so database design
and architectural design must be inputs to one another to yield a well integrated system with the
performance characteristics required.
The architectural drawing must be approved by the project sponsor, project steering committee
and the organization’s enterprise architect/chief architect/head architect where that person is not
the architect on your team. In many cases people other than another architect will not have the
ability to determine whether the drawing contains all the information required by the project,
or whether the system design is sound. They will be able to determine that each category of
information has been addressed and that the drawing meets any requirements defined for it in
the Project Charter, Statement of Work (SOW), or scope statement. Once the drawing has been
approved it should be communicated to the analysts who are responsible for producing design
specifications.
The software architects role does not end with the production of the architectural drawing,
indeed in some software development lifecycle (SDLC) methodologies this drawing will be
produced iteratively. It may be produced in stages such as the infrastructure layer first, the
domain layer next, etc. or it may be produced iteratively, one new version for each iteration. Even
projects using Waterfall SDLC methodology won’t necessarily produce a final drawing during the
project planning phase because they don’t need to. The designers need to have a drawing that
provides them with the information they need when they need it and you may need to begin
design work with the drawing you have in order to keep to schedule.
The architect must also ensure that the design captured in Functional specifications and detail
design documents conforms to the constraints placed upon it by the architectural drawing. To do
this they must review the designs to determine compliance. The architect should be a member of
any peer review teams reviewing design. This may not be possible, especially if you have to share
an architect with another project or operations so at minimum the architect should review each
design and ensure compliance with their architectural design, or identify gaps where it does not.
The hardware and operating systems which are components of the system architecture are areas
of oversight for the architect. Projects which call for procurement of these items, or outsourcing
of the development of any applications, should engage the architect to contribute to product
and vendor selection criteria. Some architectural drawings may specify hardware and software
depending on the solution being implemented, in which case the information should be
included in the architectural drawing. Where requirements for these things are less well defined,
the architect should make certain that selection criteria properly reflect their architectural
requirements and that the statement of work for any outsourced software is correctly written. In
projects where software development work is outsourced, the architect’s role will be the same as
if the work were being done in-house. Large projects which require the vendor to staff their team
with a software architect should have their architectural design overseen by the architect for your
project.
Finally, the architect should also be called upon to analyze any changes to software design or
functionality that could cause a change in the architecture. Your architect will be the right person
to analyze any request to determine where a change in the design of one system component
would impact on other components of the architecture. Once the architect has determined if a
change in other components would be required, and what the nature of that change would be,
it’s up to your design and build gurus to assess the cost of that change.
About the Author

Dave Nielsen is a principal with three O Project Solutions, the vendors of AceIt©. Dave was
also the key architect responsible for the creation of the product. AceIt© has prepared Project
Managers from around the world to pass their PMP® exams. You can find endorsements from
some of his customers on three O’s web site (http://www.threeo.ca/).

The High Costs of Building the Wrong Product

Costs explode when you start building the wrong product at the early requirements stage. Learn how
you can avoid it.
As product managers, we often talk about

creating the right solutions with our products.
Understanding the very real problems that
our customers face, understanding the very
real opportunities our markets present, and
manifesting that understanding in a product
roadmap.
Other than being “not as good,” how expensive is

it to build the wrong product?
The Cost of Poor Quality

There’s an analog to the market dynamics of making poor product decisions – executing with
poor quality. Many research studies and articles have identified the market impacts of poor
quality. This has become so well accepted that people today cite it like a law of physics as the “1-
10-100 rule.” The primary conclusion of that research is that ten dollars spent on fixing bugs:
Costs and saves $10 when you catch (and fix) the bug during implementation.
Avoids $100 in costs when you catch the bug during QA and send the product back to
development (then test again).
Avoids $1,000 in costs versus waiting until your customers catch the bug in the field, causing
the team to remedy the problems, rush out a patch release, and/or go to heroic lengths to
manage a PR problem.
This is an opportunity in front of your product team – a 100x payback from investing in quality
during the development process. Of course, be pragmatic about it - if the cost of testing exceeds
the cost of bugs, don’t test.
This is not a solved problem, by any stretch, but the solutions and methods to solve this problem
are well understood now. In fact, a 2001 article by Barry Boehm and Victor Basili shows that in
some cases, the labor costs to resolve bugs can be as low as 5:1 – when considering a subset of
smaller systems, when using more “agile” processes. That lowered ratio does not take into account
the lost market opportunities and the costs of cleaning up collateral damage to your product –
just the immediately realizable (and measurable) costs of resolution.
One very real problem, when talking about “bugs” is in defining what a “bug” is. And the definition
of a bug is a matter of perspective. A developer can reasonably assert that “if it meets the spec it is
not a bug, it is working as designed.” What if the spec is wrong? The developer may not be guilty,
but collectively, your team screwed up. There’s a “bug” in the requirements.
What Is a Requirements Bug?

Now things are getting interesting.
If you wrote a requirement that you interpret as

“A” and your developers interpret as “B” – you
definitely have a bug – the team won’t build
the right product. For each $1 you could spend
making sure you have bug-free requirements,
you could:
Make sure you have a shared understanding

of the documented requirements through
active listening before development
begins ($1). Following the Rules of Writing
Requirements will help prevent this
miscommunication.
Wait until the engineering team is ready to demo their progress ($10). They will have to build
it again, because they built the wrong stuff.
Wait until development is complete and QA is validating that the code meets the spec ($100).
This gets tricky if you are thinking “A”, the developers are thinking “B”, and QA is thinking “C.”
In classic throw-it-over-the-wall mode, wait until the product is launched, and it is the wrong
product ($1000). Assuming “A” was the right problem to solve, the cost of entering the market
with a solution to “B”, leaving “A” unaddressed, is impressively high.
This gets interesting because the above assumes that “A” was the right problem to solve. What if
“G” was the right problem to solve, and “A” was the wrong market problem? Even if everything
(else) is working perfectly – you document requirements for “A”, the engineering team creates a
marvelous “A” and it launches without implementation errors – you still fail, and incur the 1,000x
cost of a failed product launch.
There is an even larger opportunity in front of your product team – a 1,000x payback on
discovering and choosing to solve the right problems for your customers and markets.
Would Palm still be independent if the Pre had solved a compelling problem?
Why did Intuit have to buy Mint.com – could they have embraced the same customers with
Quicken?

What is Garmin going to do now that “free” GPS mapping and turn-by-turn directions are
becoming ubiquitous? If it is “more of the same,” how much are they wasting?
Wrapping Up
I’m not aware of any studies that show that “requirements bugs” fit the same 1/10/100/1000 cost
explosion model that “implementation bugs” exhibit. Emotionally, it “feels about right” to me – it
passes my “sniff test.”
There are times when days of research would have been required to avoid or redirect a few hours
of implementation effort on projects I’ve worked on. And I’ve seen man-years invested solving
problems that didn’t involve much more research.
My intuition from products and teams I’ve worked with is that it probably averages out
somewhere around 10x.
Visit Scott Sehlhorst’s blog at http://tynerblain.com/blog/
Business Process Improvement is a Strategic

Necessity
Long-term competitive advantages require continuous business process improvement
Business Process Improvement

Overview
Business process improvement initiatives are
frequently key projects within an organization
– regardless of the size of the organization
or, frankly, the size of the business process
improvement initiative. Even if a business
process improvement initiative is targeted at an
individual department, the impact of the change
will be organization-wide. By ensuring that the
initiative is managed as a strategic project, there
are increased opportunities for success.
Process improvement initiatives are continuous. As organizations grow, they need to

continuously analyze and refine their processes to ensure they are doing business as effectively
and efficiently as possible. Fine-tuning processes gives an organization a competitive advantage
in a global marketplace.
Process improvement is a strategy and a tool to help an organization meet its long term goals
and objectives. One key goal for all organizations is to meet the demands of their clients – both
internal and external. Clients’ needs change – whether due to economic factors, new product
introductions, mergers or acquisitions, expansion or contraction. Continuously reviewing
processes for potential improvements and efficiencies enables companies to adapt effectively to
their clients’ changing needs.
Sometimes improving one process may inadvertently have an adverse affect on other processes.
For example, let’s say a company changes its sales order processing. Once that process is
improved, it becomes apparent that the improvement in that process has created a backlog in
order fulfillment in the manufacturing department. A project management approach would
address such issues as part of the risk planning, and the order fulfillment process would have
been reviewed as an extension of the sales order process. Or, the initial project would have been
assessed to determine if making changes to the sales order process would be beneficial to the
company as a whole, given investments needed for other parts of the company.

Business Process Improvement is a Strategic Necessity
The following graphic depicts a lifecycle of a process improvement initiative:
Although a project has a defined beginning and a defined end, in this graphic we are depicting
a cyclical environment for continuous improvement. While this may be confused for ongoing
operations after deployment of the initial process improvement project, it should, rather, be
looked at as a separate project for each cycle of improvement. While monitoring is operational,
once a need for improvement is recognized; a project with a defined beginning and a defined
end and with set goals and objectives is established.
When process improvement initiatives are formally undertaken, by a project team led by an
experienced project manager (experienced in process improvement-type projects), the following
high-level overview steps will likely comprise the project work:
Documenting the current process to be analyzed.

Measuring the current process (gathering metrics) and developing a baseline. Metrics may be
customer-based or organizational-based.
Customer-based metrics may include:
Customer satisfaction
Service level
Time to market
Accuracy of customer orders
Organizational-based metrics may include:
Utilization of resources
Manufacturing line utilization
Cost per unit for development
Validating the documented current process and ensuring metrics are baselined appropriately.
Setting new metrics for the process based on organizational long-term goals – e.g., one
improvement may be to go from 85% customer satisfaction to 93% customer satisfaction over
a 9 month time period or to reduce cost per unit from $25 per unit to $15 per unit over a one
year time period.
Analyzing the process as documented to make improvements.
Design and develop changes to the process to ensure improvements as desired.
This, along with documenting a process, can be the most significant amount of time on
the project.
Validate the design to the process.
Implement the new process change.
Review and measure the results of the new process change.
Measure against baseline metrics in a designated time period.
Overview of a Case Study: Process Changes for a Manufacturing Company

This paper will provide a high level overview of a case study of a manufacturing company that
saw the value in taking a project management approach to a process change initiative.
Overview
Company XYZ has been aware that their production of widgets will not continue to satisfy clients’
demands. They have seen an increase of 10% year after year for widgets over the last 5 years
with no end in sight for the increase in demand. The CEO had asked an internal team to review
current manufacturing processes and propose changes to the processes, along with upgrades to
equipment to meet the demands for the future. When the team’s proposal was submitted to the
CEO, it recommended an upgrade to manufacturing equipment and a redesign of the production
line with no solid metrics relating to the number of anticipated increases. Also missing (and
critical to the outcome) was an analysis of what would happen in procurement, delivery, as well
as warehousing, if these changes were made to the manufacturing process, and whether these
departments would be able to manage those changes. After seeing such deficiencies in the
team’s plan, and with past experiences in such projects at another company, the CEO chose to
engage a project management consulting company, ABC Projects, to outline a project plan for
this initiative. ABC Projects specialized in process improvement initiatives. The CEO knew that
these efforts were more likely to be successfully implemented when run as a well-managed
project.

The Project Plan

ABC Projects outlined a project plan with tentative timelines and cost ranges until discovery was
completed. The project plan included the discovery and identification of needs for increased
production, as well as identification of affected departments and/or processes if the increase in
production were carried out.
ABC Projects knew from experience that other areas besides the manufacturing line would be
affected. For example, procurement had a set budget for purchases. The expenditure necessary
for materials that were not ready to be used in manufacturing would wreck havoc on cash
flow and require consideration of how to store materials until they are ready to be used by
manufacturing. Further, additional vendors from which to purchase the materials would need to
be identified, should the current vendors be unable to meet procurement’s increased demands.
Alternative vendors needed to be in place before any supply issues arose. It was evident that the
processes for procurement must be very closely integrated with the manufacturing processes to
maintain an ongoing flow of materials to production.
The project team developed a detailed plan for identifying the stakeholders and how they would
proceed to gather the data necessary to accurately document the manufacturing processes. The
plan included a detailed list of questions to ask each stakeholder to ensure that all interviewers
asked the same questions and gathered the same data. The project team knew from experience
that documenting processes required a thorough understanding of the business, because, when
being interviewed, individuals often unintentionally skipped relevant details. Thus, experienced
people were required to extract information needed for an accurate and detailed documentation
of processes.
The project team also developed a plan for potential risks and strategies for managing them
should they come to fruition. They wanted to be sure that once they determined the options
for making changes to the manufacturing processes, that they could accommodate potential
changes to other processes. They knew that changing one process would likely have a domino
effect throughout the company. For example, during one of the scenario planning sessions, the
project team found that if procurement was unable to fulfill the material needs of manufacturing
from one vendor, without a back up vendor in place, there would potentially be a shortage of
materials which would cause a delay in production or costs would increase by at least 30%. This
would be unacceptable and would ultimately cause customer dissatisfaction which could lead to
a loss of business to competitors.
The team also put together a change management plan; because a major component of the
project would be communicating changes company-wide and ensuring the appropriate people
were on-board and prepared to work with the new processes. Additionally, the project team
needed the individuals involved on the production line to be willing to test new processes as
well as new equipment with no interruption in meeting current client demand. Without support
from these individuals, this would be an impossible task and one that had a high potential of risk
associated with it.
Additionally, the project team sent out a company-wide communication so that employees knew
what was happening and why, and they asked for suggestions from employees. By getting the
input of the individuals who were doing the job day in and day out, they increased the likelihood
of success on the project.
The Work Breakdown Structure included several milestones to allow the company to move
forward with working with new processes and upgrades to equipment without interrupting the
current production schedule. At each milestone, there were several tasks for measuring progress
and comparing it to expected results and baselines. Assessments were completed regularly
to ensure the current plan held true to the objectives. At any point during the project, if the
assessments showed deficiencies from the objectives, then an evaluation of the process design
and, if necessary, a correction occurred. The Work Breakdown Structure included training time to
get individuals up to speed on new equipment.
The Risk Management Plan included contingencies should current employees be incapable
of learning the new equipment and performing their role in a timely fashion. Part of the
contingency plan was to use employees who adapted quickly to the new equipment on the new
production line and maintain the old production line with employees who learned less quickly,
until they were able to get up to speed. An integrated team concept, including mentoring, was
put in place to assist people in getting up to speed on new equipment.
Regular status meetings were scheduled with manufacturing, procurement, delivery and other
departments to maintain lines of communication and general awareness of the project status.
These meetings also served to ensure that employees were comfortable with change and were
able to participate in decisions that would affect how they perform their job.
Project Results
Prior to undertaking the project, Company XYZ was producing 250 widgets per day. At the time
of the undertaking of the process improvement initiative, client demand had just reached 250,
and demand had increased by 10% annually over the last five years and it appeared that the
increase would continue for the foreseeable future.
The directive from the executives was to improve manufacturing processes through changes in
processes as well as upgrading equipment, toward a goal of producing up to 400 widgets per
day. Based on current projections, the company would experience a five year timeline before
having to undertake another increase in production to satisfy growing client demand. At that
point, if client demand continued to increase, the company would be in a better position to invest
in another manufacturing site in order to meet demands after the five year mark.

Additionally, in the current production line there was, on average, a 3.6% defect rate in widgets
produced. One of the directives specific to this project was to attempt to reduce this defect rate
by at least half within the next two years.
The following were discovered during the project:
Capacity for procurement was limited due to cash flow and budgetary issues, as well as
storage. Any new process needed to take this into consideration once production increased
and would have to allow for a smooth flow between procurement and manufacturing.
It became apparent that once the number of widgets manufactured increased, demands on
warehousing and delivery would increase accordingly. A plan was put in place to change
warehousing and delivery processes to reduce the strain on these functions.
The project had run slightly over the projected timeline, but did remain within budget.
The increase in the timeline resulted from an underestimate of the space required to store
manufactured widgets prior to delivery. This occurred to a great extent because the decrease in
the defect rate was .06%, significantly exceeding the goal of 1.8%, thus causing an increase in the
number of widget units to be stored. Although this was not anticipated in a contingency plan it
did not cause the executives to be unhappy. It was a good problem.
Summary
A project management approach enabled the company to meet their production needs for the
future, while at the same time not disrupting their current production to fulfill client demand.
There was never a glitch in the production line while new processes were being tested and
evaluated. Continuous communication ensured that everyone was in the loop on changes to
processes and actually had the benefit of increasing participation from employees on how to
improve processes to better meet client needs. Additionally, continuous review and adjustments
to the risk management plan ensured that the end result was well thought out and tested
and ensured that any glitches in proposed changes were caught immediately and could be
addressed.
Adhering to a standard project management methodology enabled this company to implement

a very high risk project efficiently, on budget and within reasonable time to meet long term
strategic goals.
Copyright ©2009 – 2010 Gina Abudi. All Rights Reserved Worldwide. http://www.GinaAbudi.com
http://www.PeakPerformanceGroup.com
About the Author

Gina Abudi is Partner/VP of Strategic Solutions at Peak Performance Group, Inc.
She has worked with clients on a variety of strategic initiatives, including conducting Business
Impact and ROI studies for training programs and process improvement initiatives, project
management, developing strategic learning and development programs, assessing skills, and
developing mentoring programs.
Gina was honored as one of the Power 50 from PMI® - one of the 50 most influential executives in
project management, working to move the profession forward.
Gina has served on PMI®’s Global Corporate Council as Chair of the Leadership Team and serves
on the PM Summit/BA World Advisory Board. She was previously an Associate Board Member for
Simmons School of Management Alumnae Association.
Gina has presented at conferences on business impact and ROI, developing project management
best practices, building effective teams, and assessing project management skills. Gina received
her MBA from Simmons Graduate School of Management.

SOFTWARE-as-a-SERVICE
Software-as-a-Service
Cloud Computing Reality Check

A tempered examination of cloud computing’s advantages and disadvantages
There is a noise going about that

cloud computing can cut costs, speed
implementations, and scale quickly. However,
the noise may be slightly off-the mark –
particularly in product pitches!
What is Cloud Computing

Search.com provides the following definition of
Cloud Computing:
“ Cloud computing is a general term for

anything that involves delivering hosted services over the Internet. These services are broadly
divided into three categories: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and
Software-as-a-Service (SaaS). “
Cloud computing is a general term for anything that involves delivering hosted services over
the Internet. These services are broadly divided into three categories: Infrastructure-as-a-Service
(IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS).
The term cloud is used as a metaphor for the Internet, based on the cloud drawing used to depict
the Internet in computer network diagrams as an abstraction of the underlying infrastructure it
represents. Martin Banks, Associate Analyst at Bloor Research for Data Centres, told me, “I prefer
the term Exostructure – an externally sourced (and theoretically limitless) seamless extension of
an internal IT systems infrastructure that delivers information services on a fee-paying basis. This
is looking at the issue from the users’ point of view.”
Cloud Computing Service Categories
Infrastructure-as-a-Service
Infrastructure-as-a-Service, like Amazon Web Services, provides virtual server instances with
unique IP addresses and blocks of storage on demand. Customers use the provider’s application
program interface to start, stop, access and configure their virtual servers and storage.
Platform-as-a-Service
Platform-as-a-Service in the cloud is defined as a set of software and product development tools

hosted on the provider’s infrastructure. Developers create applications on the provider’s platform
over the Internet. PaaS providers may use APIs, website portals or gateway software installed
on the customer’s computer. Force.com, (an outgrowth of Salesforce.com) and GoogleApps
are examples of PaaS. Developers need to know that currently, there are not standards for
interoperability or data portability in the cloud.
In the Software-as-a-Service cloud model, the vendor supplies the hardware infrastructure, the
software product and interacts with the user through a front-end portal. SaaS is a very broad
market. Services can be anything from Web-based email to inventory control and database
processing. Because the service provider hosts both the application and the data, the end user is
free to use the service from anywhere.
A cloud service has three distinct characteristics that differentiate it from traditional hosting.
It is sold on demand, typically by the minute or the hour;

A user can have as much or as little of a service as they want at any given time; and
The service is fully managed by the provider (the consumer needs nothing but a personal
computer and Internet access).
What Cloud Computing Means to Business

Well, rather than running computer applications on an in-house computer, you run them on an
external machine, which could be anywhere in the world, and access the application programs
via the internet. It also means that the data associated with the application is held externally to
your organisation. So the application is hosted on a server with the associated data being stored
in a database – all on a server run by a third party.
There is just one more piece that we need to understand and that is that a cloud service can
be either public or private. What does this mean? A public cloud sells services to anyone on
the Internet. Amazon Web Services is the largest public cloud provider at the time of writing. A
private cloud is a proprietary network or a data centre that supplies hosted services to a limited
number of people. Just one more term that you need to understand and that is virtual private
cloud; this is when a service provider uses public cloud resources to create their private cloud.
What makes cloud computing so appealing at the moment? In a recent article [1], Nigel Stanley,
Bloor Research’s Security Practice Leader, said the following, “In an economic downturn cloud
computing oozes sexiness. The thoughts of off loading your data to a third party gets financial
types excited as they start to see how much money can be saved.” Cloud computing means that
rather than purchasing software, which would go on your CAPEX, you pay for it when you use
it so it comes off your OPEX budget instead. Banks feels that, in fact, cloud computing will also
reduce your OPEX spend as well as the implementation costs and associated consultancy costs
will be less as well. On one point that Banks made I am not sure that I would agree with in that he
felt the integration cost would also be smaller; I am not so sure and would advocate budgeting
the same as an in-house implementation.
How Can Cloud Computing Be Used in Manufacturing

CRM has been one of the first areas covered; this being piloted by salesforce.com with its launch
in 2000. Salesforce.com’s CRM solution is broken down into several modules: Sales, Service &
Support, Partner Relationship Management, Marketing, Content, Ideas and Analytics. Salesforce.
com’s Platform-as-a-Service product (Force.com Platform) allows external developers to create
add-on applications that integrate into the main Salesforce application and are hosted on
Salesforce.com’s infrastructure. Salesforce.com currently has 55,400 customers and over 1,500,000
subscribers. Why CRM? Well the answer, in my view, is due to the need to support a mobile sales
force that needs to be able to record information easily and quickly without necessarily having
contact always to the centre. Couple this with the need for the centre to have control over this
distributed workforce and you create an ideal environment for cloud computing solution.
A number of the large ERP vendors, such as SAP, provide cloud capabilities. SAP launched its
Business ByDesign in September 2007. Over the past couple of years Business ByDesign has been
plagued by some really bad press. In September 2009, SAP gave a briefing to the industry on how
it was tackling a number of the issues. These included:
Scalability issues: all customers run on their own blade servers

Overly “feature-rich”: the suite was originally designed to meet all of the needs of its customer
base instead of focusing on specific functionality
Lack of corporate commitment: SAP is cutting R&D funding and shifting resources to other
products
Runs on NetWeaver: a full instance is too heavy for a SaaS application and finding “cloud
developers” who have full Java EE stack experience may be tough
Infor entered the market in October 2008 with the launch of a SaaS version of ERP SyteLine. This
is a very typical entry from an existing vendor in that it allows a user to move seamlessly between
SaaS and on-premises deployment, or vice-versa.
Microsoft Dynamics entered the SaaS market in 2007 with the introduction CRM Live. This is run
at Microsoft data centres around the world, along with all the other “Live” products such as Live
Small Business Office. Software-plus-Services for Microsoft Dynamics ERP is the new capability
being offered. This allows a user to choose to implement their Microsoft Dynamics software as a
wholly-owned on-site solution, via online services, all or partly- hosted, or in any combination.
Oracle entered the market last year with the introduction of an offering comprising its Oracle

Sourcing and Oracle Sourcing Optimization products. Nagaraj Srinivasan, Oracle’s vice president
for EBS supply chain management, in an interview with Managing Automation in March 2009,
described the primary focus as being on automating the transactional aspects of material
procurement. The tool can be used to aggregate demand; determine whether an RFP, RFQ, or
other sourcing process is needed; compile contract terms; notify and qualify suppliers; establish
prices and discounts and conduct multi-round negotiations; and aggregate and award bids. In
addition, Oracle is offering CRM as a SaaS, called CRM On Demand.
Cloud Computing-based manufacturing solutions are emerging as viable competitors to

products from established vendors. These cloud solutions are most commonly used for supply
chain visibility, transportation management and supplier/contract negotiation. Vendors are
rapidly creating cloud computing modules to address other manufacturing issues, such as: supply
chain execution, shop floor planning, demand planning and production scheduling.
Where Else Cloud Computing Can Be Used

Christian Verstraete, HP’s Chief Technologist for Manufacturing and Distribution services, believes
a couple of areas will quickly become the favourites of manufacturing companies and these
include:
Cross enterprise collaboration

Verstraete sees cross-enterprise collaboration as being a current weak point in Supply Chain
management. The required integrated environment would require the exchange of structured
and unstructured data, of synchronous and asynchronous communication. By integrating
multiple concepts of social networking and providing them in an integrated, cloud based
environment, companies could use a variety of collaboration mechanisms to perform key
business processes without having to manage the environment. Data can be contributed by the
parties on request, limiting the sensitive data in the cloud. Mike Frichol, founder of Pragmatic
Papers, stated:[2]. “Cloud computing provides a geographically dispersed network approach that
is much better aligned to serve all these trading partners trying to communicate with each other
through different systems. Supply chains are networks. Cloud computing comprises networks for
delivering business applications anywhere, anytime – that should significantly improve supply
chain capabilities, communication and coordination.”
High Performance Computing

Verstraete foresees the needs for additional computing power, as companies increase the use of
digital models to virtually test their products and/or to understand their business environment
better through business intelligence and decision making. The models used are typically highly
parallelizable and fit well for a cloud environment as long as the amount of data they need to be
provided with is not large, when the network could become a bottleneck.
But cloud computing can get a business in hot water if they have not thought through the many
consequences, and this particularly means data security. Stanley states, “Without assurances that
organisational data will be totally secure in a remote site the whole concept of cloud computing
is dead in the water.” So securing the cloud is vital for its success. With companies trusting
their corporate data – their most important asset – to third party organisations, what another
of my Bloor colleagues, Peter Cooke, describes as the holy trinity of confidentiality, integrity
and accessibility, has to be assured. The infrastructure underpinning this is Identity Access
Management (IAM). Without it, system access security is non-existent.
Another worry is about the ability of the provider of the service ability to still be around
tomorrow. Raimund Genes, CTO at Trend Micro, the global security company, in a recent eBook[3].
“You need a provider that will be in business three years from now. When you give up your IT
infrastructure, you need a reliable service provider.” Banks stated that “With Cloud Computing you
must realize that your business process in no longer in your complete control. It is wrapped into
the cloud service and in the control of the provider” Therefore it is imperative that when choosing
a cloud service provider, you choose one that is likely to be there for the long-haul, or a supplier
that has a strategy to manage the situation if they are not there. Could we ESCROW agreement for
business processes locked in cloud services?
The goal of cloud computing is to provide easy, scalable access to computing resources and
IT services. Cloud computing users gain some significant economic advantages. They have no
capital expenses. They have reduced service costs because of a simplified IT infrastructure. They
do not have to buy systems scaled to their worst case use scenarios, and there is a reduction
in large client applications. The primary disadvantages are the risks associated with Internet
reliability, security and access of data, and the financial stability of the service provider.
References
1. Generating Maximum Value from your IT Security Spend - An Analyst’s Perspective. Nigel
Stanley, Bloor Research, 29 September, 2009.
2. The Cloud Computing Advantage for Companies that Outsource Manufacturing, Dr.
Katherine Jones, Industry Week, April 24, 2009
3. What to Expect from Cloud Computing, internet.com, Three Steps to Secure Cloud
Computing, Robert McGarvey, 2009
About the Author

Simon Holloway is the Practice Leader. Process Management & RFID at Bloor Research.
His background spans some 20 years as an IT consultant specialising in IS/IT strategy

planning, information management, corporate data and process modelling, business process

reengineering, software selection and project management.
Simon has several areas of specialism from his wide-ranging manufacturing, BPM and RFID
experience. For example, he is well versed in the concept of agile manufacturing and the use of
web services in the sector. He is also knowledgeable in the use of virtualisation within supply
chains.
Are On-Demand Applications Right for Your

Business?
What you need to know about IaaS, PaaS, SaaS and the emerging on-demand applications market
Salesforce.com’s recent announcement of

its VMforce platform for deploying Java
applications is the latest in a long line of
announcements from a wide range of vendors of
such on-demand (or cloud based if you prefer)
offerings. Many will be confused by the range of
offerings and the terminology used to describe
them and will be unsure of the risk and benefits.
Essentially there are three levels of on-demand

offerings. These mirror the way IT is increasingly
deployed internally.
The lowest level is infrastructure-as-a-service (IaaS). This is where pre-configured hardware is

provided via a virtualised interface or hypervisor. There is no high level infrastructure software
provided such as an operating system, this must be provided by the buyer embedded with their
own virtual applications.
IaaS is particularly useful for organisations that are running virtualised applications internally, but
may want to make use of additional capacity when their own resources are stretched. On demand
storage is applications are also considered as IaaS.
Platform as a service (PaaS) goes a stage further and includes the operating environment,
including the operating system and application services. PaaS suits organisations that are
committed to a given development environment for a given application but like the idea of
someone else maintaining the deployment platform for them.
SaaS goes the whole hog, offering fully functional applications on-demand applications to
provide specific services such as email management, CRM, ERP, web conferencing and an
increasingly wide range of other applications.
Many independent software vendors (ISVs) are now turning the SaaS model and making on-
demand applications as versions of their applications available. To do so they are often using IaaS
or PaaS for deployment.
Much of the coverage of on-demand offerings focuses on a few high profile vendors and it is
easy to think the market is restricted to them. This is simply not true; many managed hosting

Are On-Demand Applications Right for Your Business?
providers are now providing IaaS and/or PaaS as an alternative to their traditional dedicated
infrastructure hosting services. Add to this the number of ISVs now offering full or partial SaaS
and the aggregated market these organisations represent is easily as big as that of their higher
profile counterparts.
Choosing a supplier will depend on the type of platform required, the SLA on offer and the
guarantees that can be offered around security and governance.
Perhaps the most high profile IaaS platform is the Amazon Elastic Compute Cloud (EC2). Other
examples are Attenda’s RTI and Rackspace’s Cloud Servers (currently in beta and being fully
launched in the next few months).
PaaS platforms included Microsoft’s Azure, which is based on Windows and .NET (needless to say)
and Google’s AppEngine (Java based). Some PaaS offerings have a particular focus; force.com
(the original salesforce.com platform) only supports applications developed using its proprietary
APEX language. It was mainly aimed at customers wanting to extend their salesforce.com CRM
deployments and ISVs wanting to sell their applications to existing salesforce.com customers. The
new VMforce offering allows them to do that with Java as well. Rackspace’s Cloud Sites is used
primarily for web sites, although some use it for applications.
SaaS includes a wide range of offerings including enterprise applications such as CRM and ERP,
utility services including email, web conferencing and content security. The range of vendors is
huge.
So why all the fuss—what is actually in it for you, the buyer? Just focus on the cost of the platform
and all does not seem to add up. If you go out and buy your own hardware and software after 8
quarters it is quite possible that the cumulative spending on an on-demand subscription could
outstrip that of an on-premise deployment. But this only looks at hardware and software costs.
The point is that by using an on-demand supplier you are also buying access to highly secure
enterprise data centre facilities, skilled staff specifically trained to support given applications and
infrastructure, regularly scheduled backups, built in redundancy, easily shareable applications for
supporting cross organizational business processes—to mention just some of the benefits.
Add all this in and, for many, the cost is easily outweighed by the reduced risk and added value of
on-demand services. And don’t forget, at some point all that on-premise hardware and software
will need replacing; with on-demand providers that is part of the service, or at least it should be.
For many SMBs the business continuity option offered by on-demand services should be
irresistible. For many enterprises, running utility IT applications via on-demand services also
makes sense, freeing IT departments to focus on the applications that deliver unique value to
their businesses.
Conclusions
There are many more players in the on-demand market that many reports acknowledge
These range from basic infrastructure offerings (IaaS), through platform support (PaaS) to full
applications (SaaS)
The long term cost of ownership may at first not seem to add up, but take into consideration
other factors such as reduced risk and added value and for many organisations on-demand
services make a lot of sense
About the Author

Bob Tarzey is a Service Director at Quocirca Ltd. His main area of coverage is route to market
for ITC vendors to enterprises, the mid-market and small businesses (SMB). He leads many of
Quocirca’s projects for IT vendors and channel organisations.
Bob has extensive working experience of channel management. Prior to joining Quocirca in 2002
Bob spent 16 years managing channels for US technology vendors including DEC (now part of
HP), Sybase, Gupta, Merant (now Serena), eGain and webMethods.
Bob writes regular analytical columns for Computer Reseller News, The Register and silicon.com.
Bob has a BSc in Geology from Manchester University and PhD in Geochemistry from Leicester
University. Bob completed his PhD on time and on budget, within 3 years before the money ran
out - not a common achievement.

Six Things for CIOs to Consider Before Moving to Cloud Computing
Six Things for CIOs to Consider Before Moving to

Cloud Computing
Cloud computing may have been hyped but it can offer real benefits provided you address certain
issues up front. Don’t board the cloud computing bandwagon before addressing these issues.
Cloud computing has been hailed as the cure for

all IT ills. Fortunately, a measure of reality is now
returning to people’s view of the technology
and the business value cloud computing can
provide.
Nevertheless, some organisations are still not

thinking through the issues of cloud computing,
which may cause them problems down the line.
If these issues aren’t accommodated for, the
cloud can become a barrel over which providers
can stretch client organisations. So, what are
those issues and how can we minimise their
impact?
Cloud Computing Issues
1. Data ownership
The first issue is making sure you own the data and that this ownership is built into the
agreement with the provider.
The application, the hardware, the operating system and everything else can be owned by the
cloud provider. But the data is what your intellectual property is predicated upon and it has to be
acknowledged that you can take that data away with you as you see fit.
2. Data access
Data ownership does not amount to much if you are denied access to that data to migrate it away
from the cloud computing provider.
Your cloud subscription gives you access to the functionality of the application or function that
you use. If that access is removed, can you still access the data so that you can take it away with
you?
Make sure the contract allows for access to the back-end data, either directly or via the provider
offering an export capability, even after the contract has finished.
3. Data volumes
Cloud is great for off-site elastic computing, where extra resources can be applied in the form
of more compute power, or more storage. However, as that storage capability grows, so does a
specific problem.
Migrating 1GB of data across a wide-area network is pretty simple but how about 1TB? That
migration can take a long time, and if you need to work against that data in real-time, you’ll have
to plan for a degree of downtime while the data is pulled from the cloud and reinstalled against a
replacement application or function.
Even if you can agree to set up a mirrored cloud or on-premise data topology, look out for clauses
in the agreement that charge for data volumes.
Also, look at data cleansing and deduplication options, which can minimise overall volumes. If left
unmanaged, mirroring data can rapidly become a major cost if data transfers are being charged
for.
4. Data usability
Most cloud-based systems are built on a standardised database but that does not mean you can,
for example, take a copy of the database from Salesforce.com and use it on a NetSuite system.
For an on-premise system, you have to understand the database architecture. For a cloud-based
system, that understanding is just as important. Data has to be...massaged to be usable by the
receiving system. It is best to plan for this possibility early, rather than waiting to see if or when it
may be required.
5. Competitive acquisition
Why should a bank or a retail organisation not become a cloud provider? If they have datacentres
that they suddenly realise can be highly virtualised, they could find themselves with spare space
usable for little else apart from housing datacentre equipment.
These circumstances are essentially how Amazon started in cloud computing. If you are a bank
using a cloud-based service and your provider is suddenly taken over by one of your competitors,
would you be happy to allow them to run your email system for you? Probably not. You need to
plan how to migrate rapidly to an alternative.
6. The nuclear option

Six Things for CIOs to Consider Before Moving to Cloud Computing
What do you do when the chosen cloud supplier goes out of business? There has been continual
churn in hosting providers and the application service provider model of the 1990s showed how
a few high-profile failures can start a stampede.
Granted, today’s providers come from a more stable stock, and the business models should
provide greater longevity, but a degree of churn is inevitable.
If a provider goes bust, then an administrator is likely to be appointed to try and sort out the
business. Some administrators will try and sell it as a going concern, in which case there should
be fewer problems than if a predatory administrator is put in place.
But many administration companies seem to be moving more rapidly to asset-stripping. They
identify the assets, sell them off, pay anything that is owed to the biggest preferential creditors -
usually the government - pay their own bills and then see if there is anything left.
This approach brings its own problems, the first of which is gaining access to your data. You can
deal with this situation by implementing suitable data topologies with full-image or incremental
and snapshot capabilities to a backup storage facility. The real problem is how the administrator
disposes of equipment.
You won’t have to bother about the application servers, because there’s no intellectual property
in there. But storage systems? If these are just being packed up and resold, then copies of your
data could well be sold on in a usable format.
It is imperative that the contract includes data encryption at rest so data is more difficult for
people to do anything with on storage recycling.
It should also be part of the contract that storage units are cleansed of data at a forensic level
before being disposed of, no matter who owns the cloud company or data facility at the time of
disposal.
The cloud has many benefits and will form an increasing part of an organisation’s IT platform. But
to get the most from it, forethought and planning is required. Dealing with data so that it doesn’t
become a major issue should be a priority for those deploying cloud services.
About Quocirca
Quocirca is a user-facing analyst house known for its focus on the big picture. Made up of experts
in technology and its business implications, the Quocirca team includes Clive Longbottom, Bob
Tarzey, Rob Bamforth and Louella Fernandes.
Will Project Managers Have Their Heads in the

Cloud?
Cloud-based applications and Internet-based systems are rapidly gaining popularity. Read on to find
out some clear advantages of the cloud for enterprise project management and a few things to be
aware of.
The CEO of Microsoft, Steve Ballmer got this

year’s slogan going with a bang, “We’re all in!”
he cried to the crowd early this year. It’s a poker
analogy of course. “All-in” refers to betting all of
your chips; putting all your money on the next
turn of the cards. You’re betting everything that
you’ve got the winning hand.
What Microsoft has been betting on is moving

many of its products to the “Cloud” where users
can consume them online. As I was talking
about this new message of Microsoft’s to my
wife it prompted the obvious question, “What is
the cloud?” I had to think about it a minute. What does the IT industry mean when we talk about
Cloud Computing and what are the implications to the project management software industry
and to project managers in general? First of all, like almost anything in the IT world, there are
numerous meanings; the cloud designation comes from network diagrams which had to depict
connections to something out in the Internet.
So the “Cloud” can just refer

to the Internet in general as in
“somewhere out there”. In recent
years though, applications that
have been only available via the
Internet have sprung up. There are
numerous examples. Salesforce is a
CRM, Contact Management System
that isn’t installed at your local
office. You pay a subscription as an
organization and then access the
application through your Internet
Web Browser online. Google Apps
is a suite of Applications such as

Will Project Managers Have Their Heads in the Cloud?
Word Processing, Spreadsheets and Presentations that is available only through your browser.
Microsoft’s office.live.com offers Word, Excel and PowerPoint this way also. Almost everyone
knows about Hotmail, Yahoo Mail or Google’s Gmail. These are all Internet-based email systems
that you don’t install in your office but rather access through an Internet browser or application of
some kind. All of these examples are applications that live “in the cloud”.
One of the big concerns over cloud-based applications has been the security of the information.
As many of us have seen in the past, social networking systems like Facebook are having its
clients pay for its “free” service with a bit of their privacy. So, a new term sprang up, “private
clouds”. This seems like a contradiction in terms but actually it’s referring to something of a mix
of terms. A private cloud application is one which is not installed on your premises on your own
servers, but rather is installed on the servers of a service provider who dedicates that server for
your organization’s use. So, the privacy of the information, even though it is being transmitted in
some way over the Internet, can be made much more secure.
OK! So that’s cloud computing, but I’ve yet to mention project management applications.
Don’t worry, they’re there. There are a number of project management applications that are
made available in both the Internet Cloud and Private Cloud models. Many clients we know are
now having their enterprise project management applications such as Oracle’s Primavera or
Microsoft’s Project Server hosted by a third party service provider. There are also software vendors
who have designed their whole application to be available only through online subscription and
your Internet Web browser. Take a peek at Canada’s AceProject based in Quebec city or Daptiv
based in the US in Seattle. There are many more examples which you can find easily through an
online search.
Your own applications, even though internally developed can also be moved to the cloud. There
are many environments to choose from. Take a peek at Amazon’s EC2 Elastic Computing or
Microsoft’s Azure environments, for examples. You can get your own virtual server at Amazon
or a complete computing environment at Microsoft. More and more organizations are finding it
attractive to offload their capital costs to such services in favour of regular operational costs as a
method of improving cash flow and not tying up working capital in actual equipment. “Shift your
CapEx to OpEx” say the salespeople.
With enterprise project management systems becoming more and more complex to support
internally, there is some attraction to all of these models. Enterprise systems typically depend on
a “stack” of technology. Take Microsoft’s Project Server as an example. We depend on Windows
Server, SQL Server, Activity Directory, SharePoint, Internet Explorer and Exchange Server to make
all the features in Project Server appear. If we can put responsibility for all of the server-based
portions into the hands of a third party who specializes in such things, this can become attractive.
We estimate that more and more enterprise applications will not only become available from a
cloud-based service, but that more and more organizations will insist on such applications being
subscribed to that way, so look for more and more of your enterprise level applications to appear
in the cloud. That being said, I don’t expect that at any time in the medium term we’ll see a
movement completely away from locally installed enterprise systems. Also, regardless of what’s in
the cloud, there will always be a market for individual project management tools.
So, what should you do? For the moment, probably not much that’s different but every
organization looks at their internal tools every few years and I predict that people who are
looking in the 2012 to 2015 range of time will be thinking about whether to install those tools in-
house or in the cloud.
There are some clear advantages to installing in the cloud and a few things to be aware of.
On the advantage side, the maintenance effort of keeping the enterprise system available,
patched, upgraded, backed up and operational falls to someone else. Suppliers of such solutions
also keep staff experienced in the maintenance of the tool, so you don’t need to get stressed over
acquiring those skills internally or keeping them current. There’s also a financial consideration.
Installation of a new enterprise system is typically quite expensive; requiring hardware, operating
systems, databases and a range of other supporting technology. Expertise must often be hired
to do the basic installation before you can even think about configuration of the tool for your
particular use. These costs can be amortized over time in a cloud-based model and woven into
the regular subscription fee. Of course, if you evaluate the total cost of ownership, it may appear
more costly to pay month-by-month over the long term. You’ll need to check your business case
carefully to ensure you’ve allowed for all the costs and cost savings of each option.
On the disadvantage side, you’ve got a few basic things to think about. First, working with an
application in the cloud means that every one of your users has to be able to get to the cloud.
That means Internet access to the application without the firewall or other restrictions keeping
you from it. Security also becomes a concern. If you’ve got a contract in certain industries (like
Defense or Healthcare) then you may have legal requirements for security that must be complied
with. If your organization is used to doing custom modifications to your applications then that
may be a factor also. Some cloud-based applications are not designed to be modified by the
end-user. This may be more restrictive than you’re used to. For some applications, bandwidth and
performance may be issues. One common question is to find out where the application and its
associated data will be physically located. Just because a service has an address that is local to
you doesn’t mean they house their data there.
Cloud-based applications are here to stay and you’ll need to include “Should we move it to the
cloud?” as one aspect of future enterprise project management and enterprise project portfolio
management applications.
About the Author

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He

Will Project Managers Have Their Heads in the Cloud?
has an economics degree from Montreal’s McGill University and over 22 years experience in
the automation of project control systems. He is a long-standing member of both the Project
Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the
founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been
published in numerous publications including Fortune Magazine, Heavy Construction News, the
Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part
of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches
Advanced Project Management at McGill University’s Executive Institute. He can be reached at
chrisv@hmssoftware.ca
Agile
AGILE

Agile Removes Limitations

If you decide to make an Agile change in your origanization, be prepared to change the rules now.
Have you introduced a major process change

like one of the agile methods – e.g., Scrum, XP,
etc.?
Have you spent any time thinking about the

existing rules and other structures in your
organization that may need changing?
If not, you may run into trouble when agile

teams bump into existing processes in your
organization such as:
Separate build/deployment processes

Formal audit or compliance processes
Other development teams using more traditional methods
Centralized teams and their architecture, infrastructure, design, etc.
Human-resources-related policies and processes like career tracks, evaluation criteria, and
more
Agile Is a Change for More than Just the Development Team

Agile methods are described as software development methods. Most introductory material, like
the Agile Manifesto, describe how agile teams are organized and act but don’t describe some of
the things that happen outside the development teams.
When your teams start using new methods, they will act in a drastically different way from the
norm, especially in an organization that has not otherwise changed. There is bound to be some
conflict.
When you bump into existing processes or rules that seem to get in the way of your agile teams,
you will have an important choice to make: ignore the rule, follow the rule, or try to change it.
Option 1: Ignoring the Rules – I Hope You Have Good Air Cover
This is perhaps the simplest option but one I do not generally recommend. If you have sufficient
leadership support, you can be exempt from following the rules. Though this will allow you to
make progress in the short term, it may cause big problems in the long term, such as:
Agile
Breeding distrust between development teams and other groups/teams when they are
excluded and ignored
Making it easy to say that agile is just for [insert your generalization here--small, co-located,
simple, unregulated, etc.] projects and doesn’t scale
Deferring big problems, potentially allowing them to fester and build up resistance to agile in
the organization
Not utilizing the greatest source for change potential – people!
Option 2: Following the Rules – Proliferating Local Optimization

The organization created rules and processes – surely for a good reason. Shouldn’t we be good
corporate citizens and follow them? In doing so, other groups and teams will take agile teams
more seriously and will allow your teams to slip in alongside teams using other methods, nearly
unnoticed. Depending on the rule we are dealing with, just following may be the right approach
for the time being. However, before you choose to go along with the existing process or rule,
consider the shortcomings of this approach:
It introduces a high potential for local optimization – improving one part of the process while
leaving other parts of the process in place. Though your teams may get more stuff done,
delays will still exist in other parts of the process, possibly resulting in little or no overall
improvement to the organization.
It increases work for your teams to meet the requirements of the existing process or rule.
You might find yourself creating artifacts or taking steps that don’t add value or reduce risk
just to follow the process or rule. (See the example below, which focuses on an existing audit
process.)
It gives the impression that agile is only about the development teams and has no
implications for the rest of the organization.
Option 3: Changing the Rules – Becoming the Agile Organization

Congratulations, you have decided to take the road less traveled and help your organization
become better! Despite the difficulty of doing so, this approach will foster trust, gain additional
support for the change, and leverage the great skills and knowledge of people in other teams and
groups. It will also enable your teams to get more done when they aren’t burdened with process
for the sake of process.
I use a fairly methodical technique for this type of situation. It is proposed by Eliyahu Goldratt[1]
in his various writings. Goldratt says that organizations make rules to deal with/operate in the
presence of limitations. By rules, I mean rules, processes, structures, and other arrangements and
things. Technology (see the dictionary definition) improvements remove limitations. For a change
to truly take hold and succeed, the rules that were made to operate in the presence of the old

limitations must be eliminated or changed, and new rules created to deal with new limitations. [1]
How can we do this? Follow these steps:
Determine which old limitations the new process eliminates. For any process step or rule that
you encounter, determine why the rule exists. Techniques such as the “Five Whys” and others
can help you do this. Sometimes, documentation or experts in said process can help you do
this even more quickly. Consult them if possible!
Remove the rules that existed in the past to overcome the old limitations. Agile methods
provide us with principles and practices that overcome many limitations of the past. Validate
that the limitations the existing process or rule was made for are handled by the new method.
Ensure that those who need the existing process understand this and adapt appropriately,
and help them to do this.
Determine potential new limitations. With any new improvement comes the need to focus
on different limitations. This is what continuous improvement is all about. Identify the new,
important limitations and adjust your processes and rules to deal with those.
Repeat! Repeat this process and combine it with frequent retrospection. You’ll soon be on
your way to embodying continuous improvement in your organization.
All the rules that were made when older limitations existed, if they continue to be your modus
operandi, will sap away the ability to improve continuously and embody the change you are
trying to make, leech away energy from your change agents, and eventually result in a transition
that is mediocre at best. This situation makes it appealing to create a hybrid method, such as
combining the Unified Process with agile.
There are other aspects of agile transitions that are important to consider, but changing the rules
is a major one that is often neglected due to how difficult it is. Any time you feel like customizing
your agile process with something from your former processes, ask yourself if it is because you
have found a rule that needs changing!
Reference
[1] Goldratt, Eliyahu. Beyond The Goal. Your Coach in a Box; unabridged edition (September 1,
2005).
The article was first published on StickyMinds.com.
About the Author

George Schlitz is co-founder of BigVisible Solutions, a consultancy that focuses on large-scale
agile adoptions in diverse industries. Bringing knowledge of agile, lean, systems thinking, and
theory of constraints to his clients. His passion is helping clients overcome the challenges of
Agile
enterprise change using a wide array of techniques. George’s leadership experience in business
and as a military officer help him excel at coaching and mentoring of leaders and teams. George
is a Certified Scrum Coach (CSC) and a certified Project Management Professional (PMP). If you
have questions, or would like help with large scale agile endeavors of any kind, George can be
reached at gschlitz@bigvisible.com.

Business Analysts Mitigate Agile Project Risks

New information shows that business analysts add significant value to agile projects
The agile methodology, like many concepts,

is based on an “ideal” setting or environment.
In the agile domain this usually constitutes
a 100% co-located team of generalists who
have unfettered access to the primary business
stakeholder. Working in an ideal environment
makes sense when you are describing theory,
but organizations can find this perfect
environment unachievable due to basic business
constraints: resource skill sets, location, and time
allocation. These constraints present barriers to agile adoption, can hinder productivity, cause
frustration amongst the team, and can lead to project failure.
To mitigate constraints and foster the development of a simulated ideal environment agile
development teams should incorporate the role of the business analyst.
The introduction of business analysts into their agile software development methodology may
seem counterintuitive to Agile practitioners. After all, agile purists have been saying for years to
cut detailed requirements gathering cycles out of the equation and rely on direct communication
between users and developers. What some do not realize is that business analysts do more
than elicit requirements and these unique skills not only adapt well to the agile methodology,
but greatly improve it. In their role of developing requirements business analysts have built up
core competencies such has effectively communicating with distributed resources, facilitation/
elicitation, as well as a deep understanding of an organization’s business environment and
enterprise architecture.
Each of these core competencies brings a unique value to agile projects. They should be
leveraged whenever possible to mitigate many of the risks that agile projects traditionally face:
Working with co-located teams

The lack of “generalist” resources available to agile projects
Waste caused by miscommunication with the business
Alignment with enterprise architecture and business strategy
In reality, business analysts are not “agile road blocks”, but resources who agile practitioners can
put to work.
Agile
Bring Remote Resources into the Mix

More and more businesses are adopting a ‘virtual office’ where employees work from home or
remote locations. Unfortunately, this is bad news for agile teams who have become dependant
on in person communication. Today’s agile development teams need to adapt to this reality,
finding ways to replicate the face-to-face communication that a successful implementation of the
development methodology demands.
For the business analysts these challenges are nothing new and have been overcome in the
waterfall world by applying highly tuned and specialized collaboration techniques, such as
business process diagrams, context models, and use cases which can also succeed in the agile
environment. Through the construction of models and the introduction of basic requirements
collaboration techniques, JAD sessions and virtual stand up meetings, the BA can open up lines
of communication between co-located and remote resources. In this way the BA can work to
simulate the team room environment using software tools and collaboration techniques to
replace the whiteboards and index cards.
Put Specialists to Work

A small group of generalists, individuals who hold multiple roles on a project (design, develop,
test, and deployment), are the ideal team for projects following the agile methodology.
Unfortunately, generalists are far and few between making them difficult to hire. At the same
time training generalists is not easier, requiring employees to complete multiple projects in
numerous roles to build their skill sets. In most organizations not all agile project team members
will be generalists. For agile projects to succeed without the benefit of generalists they need
a bridge builder, someone who can work and communicate across multiple disciplines while
ultimately keeping concerns of the business in the forefront.
Business analysts bring a breadth of knowledge to bear on software projects. In their role as
a communicator and liaison they are tasked to work with developers, testers, implementers,
managers, and almost all roles in the software development lifecycle. This interaction has given
them a wide breadth of knowledge over the entire SDLC. While they may not know all of the
intricacies related to the tasks associated with these roles or be able to perform them on their
own, they can provide a bridge of communication to resources that can. The use of generalists
on agile projects is ideal, because they have a depth of project experience and knowledge that
increases their productivity. If we can inject some of that project knowledge through an effective
liaison to other project members we can extend the reach of agile development by incorporating
staff which normally would not be equipped to take on all development tasks. This new resource
allocation reduces project and training costs will minimizing effects on productivity.

Communicate Effectively with the Business

Agile methodologies minimize risk through the introduction of short iterations or sprints for
developing and deploying software. The underlying concept behind this approach is that if a
business user or stakeholder does not approve of the software solution, it can be quickly changed
in the next iteration. This approach works when experienced developers know the facilitations
skills to elicit a potential solution from the business users. However, if the agile developer was
able to gain a clear understanding of the business need and provide a useful solution project
effort is wasted twice. Once on the sprint which got the solution wrong and then again on a
sprint to make the correction.
Constant, direct, and meaningful communication between business stakeholders and developers
reduces waste caused by misunderstood requirements, but only if that communication is
effective. A frequent hurdle presented by this concept is that the role of requirements gatherer
can be unfamiliar territory for developers. In many cases they do not know which questions to
ask, what information to capture, or how to communicate with the stakeholders.
A skilled business analyst is a master of effective business communication and requirements

elicitation. Agile projects can utilize this expertise by allowing the business analysts to act has
an elicitation mentor to the project’s agile developers. In this role the BA can work hand-in-hand
with developers to mentor and teach techniques for meaningful communication. By asking the
right questions and constructing models to represent the future state solution developers will
learn how to get the information they need to get the technical solution right the first time.
Reducing wasted effort, contributing to on-time delivery, and implementing the features that the
business users really need.
Think Beyond the Project

Even when agile developers are able to skillfully communicate with their business users the
conversations tends to center around topics directly related individual issues surrounding the
current project or system under development. Specific user needs, related business problems,
and possible solutions are exactly what should be discussing, but this isn’t always the entire
picture. That being said, it is a common occurrence for developers and business users to take
a narrow point of view when constructing a new system, focusing on specific features and
challenges faced by the user who is sitting in front of them. The problem with this approach is
that an enterprise point of view is not considered. This lack an enterprise architecture focus leads
to duplicate data, siloed systems, and missed opportunities for cross-business integration.
By assigning a senior business analyst, to serve as an enterprise architect, to the agile project
the team gains a 30,000 ft view of a project including a perspective of how it relates to the
organization as a whole. Bringing a sophisticated level of business knowledge to the project, the
BA’s point of view provides business level context to the problem and the solution. This guidance
Agile
ensures that the technical solution is inline with the current business objectives, constraints, and
that the solution can be incorporated into the established enterprise architecture.
One method of ensuring alignment is the use of the Business Driven Development, a practice
which focuses on building technical solutions that directly satisfy business requirements. To
ensure alignment to business requirements a model-driven approach is leveraged which takes
into account the business strategy, requirements and goals and then transforms them into an IT
solution.
Agile development is not perfect. As with any methodology there are challenges. But, these
challenges can be mitigated. The introduction of a business analyst, and their experience in
communication, elicitation, and enterprise architecture, to an agile development team can
reduce risks and improve project success and agile adoption rates.
We often use the acronym “BA” as short hand for Business Analyst. But, when properly
incorporated into a project BA stands for Better Agile.
About the Author

Matthew Leach is a Consultant with Doreen Evans Associates, Inc. (DEA), a professional services
firm committed to business analysis and requirements excellence. He can be reached at mleach@
doreenevans.com and http://www.doreenevans.com.

The Marriage of Lean, Scrum and Extreme Programming (XP): How to Align Agile Across an Organization
The Marriage of Lean, Scrum and Extreme

Programming (XP): How to Align Agile Across an
Organization
Increase your chances of adoption, productivity and general success by aligning Agile methods for
Lean, Scrum and Extreme Programming
Over the years, many flavors of Agile have

emerged: Scrum, Lean, Feature Driven
Development (FDD), Agile Unified Process (AUP)
and Extreme Programming just to name a few.
These methods have numerous complementary
and distinguishing features, but the gamut of
choices can be confusing and disorienting - as
if being told to choose the best from 31 flavors
of ice cream. Return on Investment (ROI) is
important to me, so Lean must be the answer.
But wait, I also want to be agile with my business
priorities so I’ll choose Scrum. On the other hand AUP facilitates scaling, so... we are left wanting a
simple question answered: “Which Agile method should I choose for my organization?”
I have found that one can view an organization at three levels: the Executive/Project
Management Office (PMO), the Management/Project and the Development/Delivery. While
the organization typically (or hopefully) has aligned goals, each level has their own sub-goals,
focus and deliverables. A strategy-focused executive’s eyes will glaze over if you evangelize the
virtues of Extreme Programming (XP) such as continuous integration; these technical details are
so foreign to the executive that you might as well be discussing the virtues of object-oriented
programming. However, the executive will hungrily ask for more information and how fast can we
get started if you describe creating greater shareholder value by removing waste and optimizing
across the organization, i.e. Lean.
So, as Agile matures within organizations we find the question, “Which Agile method do we
choose?” is revised to, “Which Agile METHODS do we choose?” I have found that the various
organizational levels align near perfectly with three specific Agile Methods: Lean, Scrum and
Extreme Programming. In this article, we will look how to best align Lean, Scrum and XP across an
organization.
Agile
The Organization as a System

Imagine on an episode of the T.V. show “House M.D.” the brilliant, but curmudgeonly, Dr. House
sees a patient suffering from severe lower back pain. She has suffered for years and gone to
numerous doctors, but nothing has worked. After a cursory glance, House asks her to stand
up and attempts to balance a book on her head. The book slides down to her left side and falls
to the ground. House tries again and the book once more slides down to her left side. House
stares at her and tersely says, “What you need are new shoes.” “What?” she surprisingly asks. “New
shoes! Your left leg is slightly shorter than your right. You need a lift added to your left shoe and
then your back will be fine,” House states as he walks out of the office. While the other doctors
neglected to detect the cause of her pain, House again proved his reputation as an unparalleled
diagnostician by looking at the whole system and relating her shorter leg to her back pain. He
performed “System Thinking” (Smith, 2007).
What is “System Thinking?” Simply put, System Thinkers “view the world, including its
organizations, from a broad perspective that includes structures, patterns and events, rather
than just the events themselves” (McNamara, 2005). Based upon System Theory, System Thinkers
understand that “like a living body, an organization is best understood as a whole, rather than
in parts.” For example, breaking up an elephant doesn’t create a bunch of little elephants…just
a mess (Smith, 2007). The concept of an organization as a living organism inspires one to look
at a company’s organizational levels not as mutually exclusive divisions, but rather as mutually
dependent sections of the whole. In following sections we’ll see why this view facilitates Agile
successfully fitting across an organization, but first let’s look at a simplified breakdown of an
organization into levels.
On the Level (of an Organization)

A large corporation, or organization, over time typically migrates towards a leveled structure
where employees are divided along either functional or corporate responsibilities. I have
witnessed both ends of the spectrum: small start-ups where everyone on equal footing wears
most every hat and massive corporate entities where hats are individually distributed - line
managers, functional heads,
workgroup leaders and
relationship managers just
to name a few. While every
company differs, most
people can relate to the
following software product
delivery focused corporate
organizational levels and
responsibilities (diagram 1.1):

Each level has distinct goals (where they want to be) and objectives (how they get there). The
executive focuses on the strategic corporate and shareholder level. The project manager focuses
on the team and product delivery level. The developer focuses on the engineering and task
delivery level. Each group usually only has a superficial understanding of the levels outside of
their own, with the middle-child project management the most universally aware. For example,
as a developer I once received the executive level defined corporate goals of “Client First: Foster
Client Trust and Increase Client Value.” I understood the goal, but as a developer I honestly had
no clue on how to take action other than to keep it in the back of my mind – the corporate
mantra didn’t directly apply to my developer level goals and objectives. On the flip side, I once
witnessed a newly promoted developer to project manager attempt to discuss with an executive
that we needed to re-organize the directory structure in SVN (a source code control system).
The executive, so far removed from the hands-on development world simply stared blankly at
the new project manager – the SVN re-organization didn’t directly apply to the executive level
goals and objectives. Remember that “talking in terms of the other person’s interests pays off for
[everyone].” As Dale Carnegie pointed out, Teddy Roosevelt “knew, as all leaders know, that the
royal road to a person’s heart is to talk about what he or she treasures most” (Carnegie, 1981).
Having defined the three types of organizational levels, let’s move onto narrowing down the
numerous Agile processes.
Choosing the Right Agile (Let The Right Agile In)

I often hear colleagues new to Agile proudly declare, “We’re now practicing Agile at my company”
or “Our projects are now Agile projects.” “Fantastic,” I usually reply, “What type of Agile did you go
with?” More often than not they answer, “Um, well, Agile. There’s more that one?” My answer: “Yes.
Yes, there certainly are.”
Agile, as stated in the seminal Manifesto for Agile Software Development, is a set of principles
– a philosophy rather than a step-by-step process. Heavyweight processes (Waterfall or SDLC)
dominated the development world and were considered, well, heavy. Managers soon began
playing with the notion of doing more with less. Over time, lightweight processes emerged that
focused on collaboration, communication and adaptability. Finally, in 2001, the Agile Manifesto
crystallized the common philosophical concepts of now familiar Agile process – Scrum (1995), XP
(1996) and DSDM (1995) to name a few – into a unified set of guidelines and statements.
However, this begs-the-question, “Which of the many Agile methods do we choose?” While over
time we may see several Agile processes fall-out of favor, for now we have many types to choose
from each with unique characteristics and benefits. Three Agile processes standout as ideally
differentiating: Lean, Scrum and Extreme Programming (XP). Let’s take a quick look at their key
features (Lane, 2006):
Agile
As you can see, these three types of Agile processes each have unique strengths that compliment
one another. However, like any good superhero movie, the origin back-story usually gives us
great insight into our hero’s motivation (if the robber hadn’t killed Peter Parker’s Uncle Ben, our
superhero Spiderman would never have been born). So, let’s take a quick look at the three Agile
processes.
Lean
Lean originated within the Toyota production line as a way to remove waste, optimize across the
organization, flow value from demand and focus on those who add value. The success of Lean
at Toyota led innovators such as Mary and Tom Poppendieck to begin applying Lean to software
development. They found that Lean, as a set of thinking tools rather than a distinct process, could
greatly improve the efficiency of the software delivery lifecycle and help “shorten the time from
problem recognition to software solution” (Poppendieck, 2002).
Lean development promotes seven key principles:
Lean thinking has been applied across a myriad of industries and has been found to regularly
produce significant customer value add. Let’s look at an interesting example with the recent

decision by Spirit Airlines to begin charging $45 for carry-on overhead luggage (no charge for
luggage that fits beneath the seat). At first glance you might think this decision yet another
airline tactic to penny-pinch the customer, but consider for a moment the three main concerns
of a frequent flyer: speed, comfort and cost. When the overhead bins are stuffed, the three main
customer concerns are negatively affected. First, the boarding and deplaning takes longer.
Reduced speed and greater cost emerges as an issue the longer the plane sits idle. Second,
customers need to check carry-on bags that don’t fit in the overhead bins. Have you ever boarded
a plane and found all the overhead bins were already full (try as you might to stuff your bag into
that too small of a space)? Finally, the plane weighs more. It makes sense: more weight, more
fuel, more cost. Spirit’s lean decision to charge for carry-on baggage arguably creates greater
customer value and choice. As Spirit’s Chief Operating Officer Ken McKenzie put it, “Bring less, pay
less. It’s simple” (Huffman, 2010).
Scrum
The Scrum process provides a simple framework that facilitates team organization and getting
high-quality work without sacrificing productivity (Sutherland, 2007). The name Scrum derives
from the rugby term that refers to the “mechanism to restart the game after an infraction. It is
the general idea of a team huddling together to move the ball toward the goal” (Lane, 2006).
Like Lean, the concept of Scrum originated in the manufacturing world. At the Easel Corporation
in 1993, Jeff Sutherland first applied the Scrum concept to software development. Finally, in
1995, Ken Schwaber and Jeff Sutherland formally introduced the Scrum process after analyzing
common development processes and concluding that they were not suitable for empirical,
unpredictable and unrepeatable processes (Coetzee, 2008).
Scrum focuses on team organization (ScrumMaster, Product Owner and Development Team)
and practices (Daily Scrums, Sprints and Retrospectives). Scrum has an interesting delineation
between those committed to building and delivering software frequently (the “Pigs” – Product
Owner & Development Team) and those interested in the project but not committed to delivery
(the “Chickens” – Stakeholder & Managers). The terms “Pigs” and “Chickens” comes from a classic
joke on commitment, wonderfully illustrated below by Mike Vizdos and Tony Clark:
Agile
Extreme Programming (XP)

Extreme Programming, the most widely adopted Agile process in the US, is a “programmer-
centric methodology that emphasizes technical practices to promote skillful development
through frequent delivery of working software. [Extreme Programming] got its name when its
founder Kent Beck asked the question, ‘What would happen if we took each technique/practice
and performed it to the extreme? How would that affect the software process?’” (Lane, 2006) For
example, if code reviews and refactoring are a good idea, what happens if we go to the extreme
and do continuous code reviews and refactoring? Thus was born the four core practices XP (with
an example of each):
XP contains a lot of similar Scrum practices with the engineering elements that Scrum is
traditionally missing.
Aligning Agile Across an Organization (If the Shoe Fits…)

At this point, we’ve begun to see that the three organizational levels (Executive, Project
Management and Development) align quite nicely with three specific Agile process (Lean, Scrum
and XP), respectively. While all of the Agile processes have commonality, their sweet spots are
attuned to specific organizational levels: different “views” for different audiences. Lean shines
when applied to those with a strategic, organization and shareholder value focus: the Executive.
Scrum shines when applied to those with a team organization, management and project delivery
focus: the Project Management. Extreme Programming shines when applied to those with a
development delivery and tactical focus: the Development. Diagram 1.5 illustrates this concept.
Putting on our System Thinking caps for a moment (and never taking them off ), we must
remember to address the whole system and not individual parts. Apply Agile across an
organization and not at any one single organizational level else we risk organization goal
misalignment and an increased chance of failure, or at least less successful than we could have
been.

For Your Consideration

What about the technicalities of managing three Agile processes across an organization? In
other words, how do you actually make it work? While that answer goes beyond the scope of this
article, please consider the following as a potential guideline.
As we all know, companies’ culture and organizational breakdown can differ greatly. At one
financial company where I worked, the high-level Managing Directors often boasted that they
could still code with the best of them. The corporate focus leaned more towards a tactical
mind-set, i.e. XP. In other words, a company’s unique culture and organization will determine
the appropriate Agile fit; whether applying Lean, Scrum and XP to the afore mentioned three
organizational levels or a mixture of Agile process to the unique corporate tiers. So remember
two things: first, Agile promotes fluid and adaptable processes, thus you can practice the “Agile
Way” of keeping what works and leaving out what doesn’t. Second, always “System Think” and
apply across the organization and not to a single part.
Final Thoughts
We can view an organization at three levels: the Executive/Project Management Office (PMO),
the Management/Project and the Development/Delivery. These levels, each with their own focus,
goals and mind-sets, perfectly align with the sweet spots of three Agile processes: Lean, Scrum,
and Extreme Programming. By applying these three processes across the organizational levels
(System Thinking – applying not just to a single organizational level), we increase our chance of
adoption, productivity and general success.
I believe that we are on the verge of inventing a new way of looking at Agile: a maturation and
simplification of Agile from numerous processes to a few or even one. Perhaps even a new
process might emerge that addresses the needs across an organization. However, creating a new
process will take significant fortitude and community accord. As Albert Einstein noted, “Three
Rules of Work: out of clutter find simplicity; from discord find harmony; in the middle of difficulty
lies opportunity.”
Aligning Agile Across an Organization (If the Shoe Fits…)

At this point, we’ve begun to see that the three organizational levels (Executive, Project
Management and Development) align quite nicely with three specific Agile process (Lean, Scrum
and XP), respectively. While all of the Agile processes have commonality, their sweet spots are
attuned to specific organizational levels: different “views” for different audiences. Lean shines
when applied to those with a strategic, organization and shareholder value focus: the Executive.
Scrum shines when applied to those with a team organization, management and project delivery
focus: the Project Management. Extreme Programming shines when applied to those with a
development delivery and tactical focus: the Development. Diagram 1.5 illustrates this concept.
Agile
Putting on our System Thinking caps for a moment (and never taking them off ), we must
remember to address the whole system and not individual parts. Apply Agile across an
organization and not at any one single organizational level else we risk organization goal
misalignment and an increased chance of failure, or at least less successful than we could have
been.
For Your Consideration

What about the technicalities of managing three Agile processes across an organization? In
other words, how do you actually make it work? While that answer goes beyond the scope of this
article, please consider the following as a potential guideline.
As we all know, companies’ culture and organizational breakdown can differ greatly. At one
financial company where I worked, the high-level Managing Directors often boasted that they
could still code with the best of them. The corporate focus leaned more towards a tactical
mind-set, i.e. XP. In other words, a company’s unique culture and organization will determine
the appropriate Agile fit; whether applying Lean, Scrum and XP to the afore mentioned three
organizational levels or a mixture of Agile process to the unique corporate tiers. So remember
two things: first, Agile promotes fluid and adaptable processes, thus you can practice the “Agile
Way” of keeping what works and leaving out what doesn’t. Second, always “System Think” and
apply across the organization and not to a single part.
Final Thoughts
We can view an organization at three levels: the Executive/Project Management Office (PMO),
the Management/Project and the Development/Delivery. These levels, each with their own focus,
goals and mind-sets, perfectly align with the sweet spots of three Agile processes: Lean, Scrum,
and Extreme Programming. By applying these three processes across the organizational levels

(System Thinking – applying not just to a single organizational level), we increase our chance of
adoption, productivity and general success.
I believe that we are on the verge of inventing a new way of looking at Agile: a maturation and
simplification of Agile from numerous processes to a few or even one. Perhaps even a new
process might emerge that addresses the needs across an organization. However, creating a new
process will take significant fortitude and community accord. As Albert Einstein noted, “Three
Rules of Work: out of clutter find simplicity; from discord find harmony; in the middle of difficulty
lies opportunity.”
Bibliography
Carnegie, D. (1981). How to Win Friends & Influence People. New York, NY: Pocket Books.
Coetzee, L. (2008, Oct 6). What is Scrum? Retrieved from Swat Blog
Huffman, M. (2010, Apr 7). Spirit Airline Charges For Carry On Bags. Retrieved from Consumer
Affairs
Lane, R. C. (2006, Oct 17). A Practical Guide to Seven Agile Methodologies. Retrieved from
devX
McNamara, C. (2005 Feb). Thinking About Organizations as Systems. From Free Management
Library
Poppendieck, M. (2002). Principles of Lean Thinking. Retrieved from Lean Software
Development
Smith, K. M. (2007 28-Sep). Understanding Your Organization as a System. From Ezine Articles
Sutherland, J. (2007, Oct 14). The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process.
The Free Dictionary. (n.d.). Scrum. Retrieved from The Free Dictionary
About the Author

Geoffrey Bourne has 12 years of experience in the financial IT field, successfully managing several
globally distributed Agile teams in Mumbai, Bangalore, Hong Kong, Japan, and the U.S. He has
worked at J.P. Morgan, Goldman Sachs and several start-ups. He has a B.S. in Computer Science
from Washington & Lee University and is a certified Sun Java Developer and PMP. Geoffrey
is currently a Vice President at a major financial institution in the New York Private Bank and
Personal Wealth Management divisions and can be contacted at gbourne@gmail.com
Agile
Introducing Agile Development? Move

Gradually!
Early struggles can discourage those new to Agile development. Learn about 4 stages for gradually
introducing Agile development methodologies.
Having troubles introducing Agile Development

on your custom software development projects?
Why not try moving to it gradually?
Implementing an Agile Development

methodology on a custom (or bespoke) software
development project can be difficult and many
organizations new to the agile methodology
struggle to adopt it. One of the big ‘problems’
with Scrum (a flavour of Agile Development) is
that project-related issues come to the surface
early because the team must deliver potentially release-able software within a month. Those
issues in combination can seem insurmountable to those new to Scrum.
Typical issues/obstacles that arise include:
1. Lack of business ownership and the inability to make decisions,

2. Limited business buy-in into the concept of Agile,
3. Team communication, individual skills, and team fit,
4. Lack of trust in the team by the business.
In a traditional (waterfall) project, the team can spend months on design and when development
begins they may start with the low complexity features, thereby not identifying issues until it is
too late; forcing the project to run over-budget and/or delivering a solution that doesn’t meet the
users’ needs.
When introducing Agile Development, organizations often attempt to tackle all of these issues
head on and get overwhelmed with the new methodology, then choosing to revert back to what
they are familiar with.
Why not introduce Scrum in stages to enable an organization to deal with issues one at a time
and gain the benefits associated with solving each issue gradually?
Based on my experience as an Agile/Scrum Coach, I have found that introducing each stage
below gradually over a number of months can work effectively for an organization that is

Introducing Agile Development? Move Gradually!
struggling with Agile Development.
This article outlines a number of stages that a project team should go through in the introduction
of Scrum. Each stage is summarized and then outlined in more detail below.
The first stage introduces prioritization of requirements, focusing only on the highest priority
ones within a time-boxed two week sprint. Introducing prioritization can be difficult and issues
with lack of business ownership and inability to make decisions must be overcome to enable you
to complete this stage. The benefit gained is the ability to re-focus based on changing priorities.
At the second stage, you will overcome the obstacle of gaining business buy-in into the concept
of Agile Development and ensure that the business agrees that quality and high priority business
requirements are the top priority – over a detailed plan. You will have introduced estimation
based on story points which will give the business improved control of the project in making
decisions related to priority.
At the third stage, you will ensure the team is collaborating more closely; overcoming team
communication and development skills deficiencies. You will have reduced the number of defects
and the team will produce higher quality software quickly.
At the fourth and final stage, proper user stories and acceptance tests written by a Business
Analyst will be introduced and the software will be frequently demonstrated to users so that their
feedback can be incorporated. The business must learn to trust the team and agree to minimal
documentation and sign-off. Once complete, teams are able to deliver software that is more
closely aligned with what the user wants.
Each stage is outlined in more detail below:
Stage 1: Focus on the highest priority requirements within a time-boxed

sprint
In my opinion, the biggest benefit to be gained by introducing Agile Development is the ability
for a project team to re-focus based on changing priorities (and changing requirements). To gain
this benefit, the first step is to focus on only the top priority requirements in the first two week
iteration (called a sprint in Scrum).
Work closely with the business representative to ask the simple question ‘what happens if we
don’t do that?’ For teams that are less Agile, they will quickly realize they are working on a number
of low priority requirements that do not necessarily provide much up-front benefit to the user.
The main goal of the initial prioritization should be to identify the minimum number of features
required for the product to be released and demonstrated to the user. Teams can often think only
of the end product that includes all features.
Agile
Once the first logical chunk of work has been identified, but before any development work
begins, sit with the team to break down the requirements into tasks (referred to as sprint
planning in Scrum). Get team members to commit to estimates so that everyone is aware of what
they must do in that first time-boxed sprint. It is a good idea to use a board or software to track
the tasks and ensure they are completed within the sprint.
The new focus for the business representative should be to document detailed requirements only
for the next sprint (the next couple weeks). They must not spend a large amount of time writing
specs for requirements that aren’t coming until the next release since this is often wasted effort as
requirements and scope change.
Scrum features introduced at this stage

If you are familiar with Scrum, note that at this stage, we have not introduced many of the
formal rules of Scrum. We have identified the Product Owner by asking the business to prioritize
requirements using the Product Backlog. Prioritized requirements have been divided into a small
chunk of work called a sprint and the team has performed sprint planning and committed to
accomplishing their own tasks. In a future stage, they will commit to work as a team.
At the end of every sprint the software is released for testing. At this stage, I wouldn’t recommend
attempting to release the software to testers multiple times throughout the sprint.
Issues overcome at this stage

Issues with decision making and business ownership must be overcome to enable you to
complete this stage. It is often very difficult to identify the appropriate Product Owner who is
respected by the business. In my experience with custom development projects, the best Product
Owner is often a Senior Manager and therefore Business Analysts are required to represent that
person at a detailed project level.
Developers always tend to under-estimate their work. When I start introducing Scrum I
continually coach the developers to ‘over-estimate’ their tasks during sprint planning, but in the
first few sprints individuals often over-commit as they get used to the concept of a time-boxed
sprint.
Benefits gained at this stage

The business can see the return on their investment after a short period by gaining benefits from
a scaled-down version of the product. After only a few weeks, the team has something they can
release to the users. Because the team is only analyzing requirements coming within the next
sprint, if those requirements change, the team can re-focus in a future sprint without the waste of
business analysis on areas of the application that were not yet ready to be developed.

Stage 2: Communicate the benefits of Agile Development to the Project

Sponsor
Now that the business requirements have been prioritized, and the team is working on the most
important items using sprints, it is important to communicate this to the project sponsor.
Some coaches will suggest that this should be the first stage of introducing Scrum/Agile
development into an organization. I recommend that this is not done until after the first
stage, because until the issue encountered in stage 1 related to decision making and business
ownership is resolved, there is nothing to get agreement on from the project sponsor.
Once the requirements have been prioritized, it is important to ensure that the project sponsor
agrees with the concept of Agile Development. The biggest advantage of Agile is that the team
will provide the highest priority business requirements quickly and the solution will be of high
quality. The biggest ‘disadvantage’ of Agile Development is that because quality is not negotiable,
if issues arise, the lower priority requirements will be moved further out on the plan. In other
words, they no longer have the Gantt chart that predicts (often incorrectly) exactly what features
are scheduled when.
Instead of a detailed Gantt chart, communication with the Project Sponsor should include high-
level goals (outlined in order of priority) planned for the next release. To be able to provide the
goals planned for the next release, the developers must provide some high level estimates (story
points – relative point system to estimate development time) for each requirement. Based on this
the business is able to better prioritize and you should be able to come up with a rough idea of
which requirements will make it in to the release.
The most important concept for the project sponsor to understand is the ‘Iron Triangle’, as
depicted in Figure 1. One of the basics in Project Management is that with any project, if the
scope (or the amount of features implemented) is increased then cost and/or time must also
increase.
The key thing to focus on with Agile Development is that

because you have outlined a fixed release date and have a
defined team, time and cost will remain the same and scope
is what changes. The Project Sponsor must understand that
the goals for the release have been prioritized and if issues
arise, the quality of the product does not suffer and we
still meet the published release date – but features can be
moved out into a future release.
Figure 1 – The Iron Triangle At this stage, we have introduced estimating the product
Agile
backlog requirements using story points. I explain to the business the concept of high-level
planning using Scrum in that a release is made up of a certain number of sprints each with
prioritized features. You can also start measuring team velocity using the burn-down chart if the
project sponsor is looking for proof of productivity improvements.

The biggest issue to overcome at this stage is to gain business buy-in into the concept of Agile. If
they don’t agree that quality and high priority business requirements are the top priority over a
detailed (and unreliable) plan, then you should not proceed on to stage 3.

The benefit gained from this stage is the Project Sponsor and Product Owner now have improved
control of a project. It is much easier for them to prioritize requirements based not only on
business priority but also on estimated story points. They understand that they will be delivered
high quality software at regular intervals and it is completely up to them which requirements are
included.
Stage 3: Improve Team Collaboration and Software Quality

The team now knows what high priority business requirements they should work on and the
pressure of meeting an unrealistic project plan; which doesn’t accommodate for unforeseen
issues and changing requirements, has been removed. They should already be feeling happier –
so now is the time to get them working together more closely to help improve productivity.
Ideally the team should already be co-located, including Business Analysts, Testers and
Developers. It is now time to introduce the ‘daily stand-up’, and the sprint retrospective to enable
the team to talk about what they did well and where they can improve.
In the first stage, developers started committing to their own estimated tasks at the beginning
of each sprint. Once that is working well, you can enable team members to select their own tasks
from the planning board during the sprint. At the beginning of a sprint, rather than committing
to individual tasks, they will be committing as a team to complete all of the user stories,
which encourages self-management. The developers should help each other solve issues and
collaborate on the best approach for design using pair programming where it makes sense.
Not only must the developers communicate more with each other, but the communication
must spread to the Testers and Business Analysts as well. This is the only way we can define what
should be built and tested.
When I first started coaching one team, someone told me that he felt like software testing was
like going into an exam where they had no idea what to study since they weren’t sure what would

be covered. This was because testers were ‘being creative’ and coming up with ‘new and crazy’
scenarios to test. There were so many ‘defects’ that every few weeks there would be a long defect
prioritization session. This type of defect prioritization should never be required.
Instead, everyone should be very clear before development begins what will be tested so that the
developers can write code that meets the requirements and defects are therefore minimized.
If the goal is high quality software or zero defects by the end of the release. The only way to
accomplish this is to ensure that defects raised are ‘real defects’ i.e. there is a business requirement
(or acceptance test) that is not currently being met. To ensure defects are ‘real’, testers must
communicate regularly with the testers and developers. If in doubt, BEFORE raising a defect the
tester must clarify that the issue they are raising really is a defect. If it is a new feature, it is instead
added to the product backlog.

The team now takes part in a daily standup for fifteen minutes or less at the same time every day.
They are sharing tasks and becoming more cross-functional, working together to identify how
they can improve through the introduction of sprint retrospectives.
The team is using acceptance tests to more clearly state the ‘definition of done’ so that both
developers and testers know exactly what is expected. Software can be released to testing
throughout the sprint rather than at the end of the sprint and defects should always be given top
priority over new features.

At this stage the team must overcome people issues. I’ve worked with teams where there were
team members that either did not have the skills or the personality to work on a Scrum team. If
they don’t have the skills, that is apparent very early on because they are not able to deliver the
software within the sprint. Issues with personality I’ve seen include failure to communicate with
the testers and business analysts due to the need to work independently. That doesn’t work with
Scrum.
I have worked with a team that didn’t have any Business Analysts – just a Product Owner who
was not available the majority of the time. In this case, we attempted to have the testers and
developers write acceptance tests together at the beginning of a sprint. This was very difficult
and productivity improved dramatically when Business Analysts were added to the team.

Developers, testers and business analysts are all working towards the sam objectives in each
sprint which will enable you to reach the goal of zero defects at the end of each release (and
Agile
hopefully each sprint). This high-quality software will be provided more quickly due to increased
team velocity due to sharing tasks and increased communication.
Stage 4: Ensure requirements are user stories that incorporate real

feedback
Now that the team is developing high quality software and productivity is starting to improve it’s
extremely important that you ensure that what they are building is exactly what the user wants.
In traditional projects, a lot of up-front analysis is done and requirements may be outlined either
as technical or functional features for the developers to code, with no explanation of who needs
it and why. Because of this, the team may still be building software that does not meet the user
needs due to misinterpretation of the user (by the Business Analyst) or misinterpretation of the
Business Analyst (by the Developer).
At this stage, it is important that the Business Analyst steps back and examines the high priority
functional requirements scheduled for the next iteration to ensure that they fully understand the
requirement and are communicating it clearly.
The best way to minimize misinterpretation is to write requirements as user stories. They should
be worded in the following way: ‘As a’ user ‘I want to’ do the following ‘so that’ the following
benefit can be met. The Business Analyst must make it clear what is expected at the end of a
sprint – also referred to as ‘the definition of done’. To communicate this clearly acceptance tests
should be written.
To ensure that the team has actually developed what the user wants, at the end of each sprint,
demonstrate the solution and get feedback from the user! For software that is already in
production, ensure there are frequent releases so that real user feedback can be incorporated.
Note that the best way to enable your team to release software frequently is to introduce
automated regression testing.

Business Analysts must learn to write requirements in a new way and the business must agree to
minimal documentation and sign-off. This is only possible if you have someone responsible for
the product ownership that the business trusts.
The best way to demonstrate that limited documentation still works is to demonstrate the
solution to the users regularly and incorporate their feedback – this is a key feature of Scrum.
Ideally, the team has been producing working software at the end of every sprint, but if they
haven’t been, now is the time to enforce this.

It can be difficult to get organizational buy-in on limited documentation. Many large

organizations are resistant to this type of change due to lack of trust in the team.
Another obstacle to overcome is the re-definition of team members’ roles. I’ve worked with teams
who had an architect telling all the developers exactly what technical feature they should add.
This not only impacts the morale of the team, since they are not able to be creative, but because
the team did not know why they were developing a feature, they often built features that did not
meet the users’ needs.

The benefit gained at this final stage is that the software developed better meets the business
needs. Expectations are appropriately set with the users and the software meets those
expectations.
Conclusion
If your organization is having troubles introducing an Agile methodology on a custom software
development project, try introducing the above stages gradually. By introducing only one
stage, you can still gain the most important benefits of Scrum – the ability to re-focus based on
changing priorities. Once your team has overcome the issues associated with that stage, you can
move onto further stages and gain added benefits with each issue you work through.
In my experience, there are a large number of organizations that are adverse to change –
especially large corporations and government organizations. In these types of organizational
cultures, it is best to deal with one obstacle/issue at a time rather than getting overwhelmed with
all issues at once.
I recommend that you first ensure the business is taking ownership and making decisions. I think
it is best to focus on overcoming this obstacle first before moving onto the second stage.
Once a Product Owner has taken control of a prioritized product backlog and the team is working
on only the top-priority requirements, it is then time to explain the benefits of Agile development
to the business. Once they have bought-in to Agile and are given more control over the project, it
is then time to focus on improving software quality.
Improving team collaboration will ensure that developers, testers and business analysts are all
working towards the same objectives in each sprint will enable you to reach the goal of zero
defects at the end of each release.
The final goal is better met user expectations which I think is only possible through the
introduction of user stories, acceptance tests and regular demonstrations with users. Getting
the business to agree to new processes around documentation can be difficult as it requires that
Agile
trust in the team is established – which again is difficult to do until the initial obstacles have been
overcome.
About the Author

Lorraine Pauls Longhurst is a Certified Project Manager with expertise in the use of Agile
software development methodology (SCRUM / ADM) with LPL Software Consulting (http://www.
lplconsulting.com.au) based in Sydney Australia.

Evolving from Traditional Project Management to Agile
Evolving from Traditional Project Management

to Agile
Are traditional project management techniques failing? It’s time to add Agile Project Management
into the mix.
Traditional project management involves very

disciplined and deliberate planning and control
methods. With this approach, distinct project
life cycle phases are easily recognizable. Tasks
are completed one after another in an orderly
sequence, requiring a significant part of the
project to be planned up front. For example,
in a construction project, the team needs to
determine requirements, design and plan for
the entire building, and not just incremental
components, in order to understand the
full scope of the effort. Traditional project
management assumes that events affecting
the project are predictable and that tools and
activities are well understood. In addition, with traditional project management, once a phase is
complete, it is assumed that it will not be revisited. The strengths of this approach are that it lays
out the steps for development and stresses the importance of requirements. The limitations are
that projects rarely follow the sequential flow, and clients usually find it difficult to completely
state all requirements early in the project. This model is often viewed as a waterfall.
Today, business processes are more complex,

interconnected, interdependent and
interrelated than ever before. Additionally,
they reject traditional organizational structures
in order to create complex communities
comprised of alliances with strategic suppliers,
outsourcing vendors, networks of customers
and partnerships with key political groups,
regulatory entities, and even competitors.
Through these alliances, organizations are able
to address the pressures of unprecedented
change, global competition, time-to-market
compression, rapidly changing technologies and
Figure 1: The Waterfall Project Life Cycle Model
Agile
increasing complexity at every turn. Because of this multifaceted nature of businesses, projects
that implement new business systems are also more complex.
For years, economists have been warning that success in a global marketplace is contingent
upon the capability to produce small batches of tailored products on a tight schedule to meet
growing demands in emerging markets. However, huge cost and schedule overruns have been
commonplace in the past.[1] Looking at the numbers, the past project performance record is
troubling:
$80 -145 billion per year is spent on failed and cancelled projects (The Standish Group
International, Inc.)
25% - 40% of all spending on projects is wasted as a result of re-work (Carnegie Mellon)
50% are rolled back out of production (Gartner)
40% of problems are found by end users
(Gartner)
Poorly defined applications have led to a
persistent miscommunication between
business and IT. This contributes to a 66%
project failure rate for these applications,
costing U.S. businesses at least $30 billion every
year (Forrester Research)
60% - 80% of project failures can be attributed
directly to poor requirements gathering,
analysis, and management (Meta Group)
Figure 2: Project Performance
Nearly two thirds of all IT projects fail or run
Track Record – The Standish
into trouble. (See Figure 2 for the results of the
Group 2006 Chaos Report
2006 CHAOS Survey.)
Improving these performance records is a goal for any organization. However, if traditional
project management is somewhat ineffective, it’s time to examine other methods of designing
and delivering projects.
Agile Project Management

For projects involving a significant software component, traditional project management can
be somewhat ineffective since the requirements are elusive, volatile and subject to change. An
alternative approach, Agile Project Management (APM), is emerging in the industry. APM is a
highly iterative and incremental process, where developers and project stakeholders actively
work together to understand the domain, identify what needs to be built, and prioritize
functionality.[2] Agile methods are used when these conditions are present: project value is
clear; the customer actively participates throughout the project; the customer, designers, and

developers are co-located; incremental feature-driven development is possible; and visual

documentation (cards on the wall vs. formal documentation) is acceptable. Figure 3 depicts the
Agile Development Model.
The Agile approach consists of

many rapid iterative planning and
development cycles, allowing a project
team to constantly evaluate the evolving
product and obtain immediate feedback
from users or stakeholders. The team
learns and improves the product, as well
as their working methods, from each
successive cycle. After a streamlined
planning, requirements definition and
solution design phase is completed to
get the project underway, iterations of
more detailed planning, requirements,
design, build and test take place
Figure 3: The Agile Project Life Cycle Model in waves. This approach allows for
immediate modifications of the product
as requirements come into view. APM requires a dedicated full-time project team that includes a
customer or end user, where team members work from the same location.
The Agile Project Management Environment

Unlike traditional project management, which emerged from the construction, engineering and
defense industries and dates back to the 1950s, APM was born in the twenty-first century. In 2001,
prominent software developers from both IT and software engineering domains, convened to
arrived at a consensus on how the software development industry could produce better results.
This meeting produced the Manifesto for Agile Software Development, which states that the
“highest priority is to satisfy the customer through early and continuous delivery of valuable
software.”[3]
APM development is conducted collaboratively, with a small co-located team. This core team
usually consists of two developers who write code in pairs (for quality control), the customer/end-
user, IT architect(s), a business analyst and a project manager. The work is accomplished through
a series of sessions where the team writes code, then tests working modules of the system
and repeats the process. There is minimal documentation as the team relies almost exclusively
on informal internal communication. Again, this differs from the traditional approach where a
considerable amount of time is invested in planning and a significant amount of requirements
documentation is produced. The Agile team identifies and prioritizes the features based on
Agile
business value, and after high-risk components of the system are produced, works on the highest
value features first. This approach works if the solution can be delivered incrementally to the
customer. If this is not possible, features still can be built incrementally and then integrated into
the first release of the system.
Agile Management Components

There are several key elements that provide the basis for APM. It is important to note that these
techniques can also be used in traditional software development methods to improve project
performance. They are:
1. Visual control
This is a “cards-on-the-wall” method of planning to assist a team in organizing the work of the
project. For example, one successful Agile project team placed different color groups of cards that
represented the features of the solution on the wall. The features that were designed, developed,
tested and in production were one color, the features that were designed, built, tested but not
yet put in production (but ready to go) were another color. The team was able to see at a glance
where they were with each feature set. Visual control is a valuable technique for all projects, since
it ensures that every member of the team views the project the same way.
2. Co-located high-performing teams

In Agile development, all the key team members are co-located, including the customer/end-
user, preferably in a work room. This approach greatly increases the quality of coordination and
communication. However, this may represent a significant cultural change for IT developers.
In traditional development methods, the developers typically work independently, and rarely
interact with the customer until the solution is fully developed. Since project managers are
responsible for building a high performing team, they need to ensure everyone is working well
together and that they have been assigned developers who truly can work in this collaborative
manner.
3. Test-driven development
In cases when the customer is having a difficult time articulating requirements, Agile teams often
use test-driven development. Using the same successful Agile project team mentioned above
as an example, the test cases were often developed first, and then the team backed into the
requirement. This obviously requires more iteration between requirements, design, development
and test. The entire four-stage cycle is collapsed. In any case, Agile teams almost always develop
test plans at the same time they define requirements; if a requirement isn’t testable, then the
requirement is not yet fully developed. This is a best practice that can be used in traditional
development to ensure requirements are complete, accurate and testable.

4. Adaptive control
Everyone on the team is constantly adapting, which may make some team members nervous,
especially those that crave structure. Because of this dynamic environment, the project manager
needs to be seen as a leader, not a taskmaster. Instead of setting rigid instructions for the entire
team to follow, the project manager facilitates the team in establishing working relationships,
setting ground rules and fostering collaboration. Agile team members continuously adapt to
improve their methods as they incorporate lessons learned from the previous cycle into the next
iteration, also a best practice for any project.
5. Collaborative development
APM relies on collaboration among all team members to deliver the results, capture candid
feedback and implement learnings on the next iteration of the solution. This is one of the
strengths of APM - constant feedback and improvement. The project manager completes
the initial planning and the business analyst defines and prioritizes the solution features in
collaboration with the customer and technology representatives. Then the Agile project teams
collaborate on the design, development, testing and reworking of each incremental build. It is
this constant collaboration with the customer that promotes project success.
6. Feature-driven development
This practice greatly reduces complexity, because it allows the team to focus on one feature and
only one feature at a time. For example, one team is working on Feature #4 and that’s the team’s
only focus. They don’t concern themselves about Features #1-3. It is the business analyst and
project manager who ensure the next feature in the backlog is truly the next priority, based on
business value and risk. Typically, high-risk components or core infrastructure pieces are built first,
and then everything else is prioritized based on business value. The goal is to build the feature-
driven components with only a one-way dependency to the core system; therefore, specialized
components are independent of each other and can be created in any order or even in parallel.
7. Leadership and collaboration rather than command and control

“The principles of APM are timeless. If you look at APM, it links much more closely to leadership.
It addresses a lot of the steps that facilitate leadership much more than traditional management,”
says Sanjiv Augustine, Managing Director of the Lean-Agile Consulting Practice at CC Pace
Systems in Fairfax, VA. The project manager works with the client management, the IT
management and the key stakeholders to ensure they know the project’s status. Additionally,
the project manager removes any barriers hindering the core Agile teams. The business analyst
manages the business benefits of the project and continually focuses the Agile team on the
business need.
Agile
8. Move from C (cost) to R (revenue) focus

Features are prioritized based on value, such as increased revenue or market share. It’s the
business analyst’s role to ensure the Agile project team is not investing too much into the
development of the new solution. If so they will have eroded the business case and the project
will cost more than the organization will gain. While the project manager focuses on project
costs, the business analyst focuses on the total cost of ownership that includes not only the
development or acquisition costs of the new solution, but also the cost of operating the system
after it is deployed.
9. Lessons learned
After each cycle, the team holds a lessons learned session to determine what they can do better
on the next iteration. As the team learns, it adapts how the members are working together to
continuously improve team performance.
The Value Proposition

“The traditional project management approach,” Augustine reports, “is a linear approach where
you try to get it all done at one time. You do a lot of very detailed planning at once up-front and
then deliver it in what’s known as the ‘Big Bang’. That industrial age thinking has spilled over from
software development to other projects as well.” This is the heart of the difference between Agile
and traditional project management.
The ‘Big Bang’ now comes from the greater flexibility and collaboration APM provides. “Just
enough” planning is done up-front. As each increment of the system is built, the team gathers
input and learns from customer feedback. Since the customer sees and/or experiences a working
prototype, he or she is better able to refine or redefine requirements and describe to the team
what the organization really needs. The Agile method embraces changes that add value, and
reduces the cost of change through iterative development. Making changes to a small module
is very cost-effective, compared to designing and developing a huge system and then trying to
make changes to it.
Can Agile Project Management Work?

“At its heart, project management, whether you are doing traditional or Agile has very similar
principles. It’s about doing a good job for the customer. It’s about leading a team. It’s about
delivering measurable business results,” says Augustine. Many of these principles or practices
can be implemented into most team-structured environments. Yet, some project management
professionals may discard the principles of Agile management if they are unable to adopt all of
the components and practices. This is a mistake. For example, what happens if they cannot get
the user to sit full-time with the team in the workroom? It doesn’t mean they can’t incorporate
some of the other pieces of Agile management such as visual control and feature-driven
development. Besides, even if a user cannot be involved on a full-time basis, most users are
willing to participate on the team, especially during the testing and feature prioritization. The rest
of the time, the business analyst can represent the user while the full-time core team continues to
work together.
Incorporating Agile management techniques into projects fosters a focus on the benefits of each
feature. In traditional project management, the teams strive to finish the project on time and
under budget and often lose sight of the overall benefits the entire effort is intended to bring
the organization. It’s important to remember the strategy the project is expected to advance
as well as the total cost of ownership and not just the project costs. In this way, the benefits of
the project will be obvious, whether the team is constructing a building or developing a new
business solution.
Refernces
[1] New York Times, 11 July 2002 “Cost overruns (totaling hundreds of billions of dollars) for large
public works projects have stayed largely constant for most the last century.”
[2] Ambler, Scott W. Agile Analysis.
[3] Agile Manifesto. Accessed April, 2007
About the Author

Kathleen B. Hass, PMP is Senior Practice Consultant for Project Management and Business
Analysis, and Director at Large and Chapter Governance Committee chair for the International
Institute of Business Analysis. She is the author of Managing Complex Projects: A New Model
(Management Concepts, October 2008). Since 1973, Management Concepts, headquartered in
Vienna, VA, has been a global provider of training, consulting and publications in leadership and
management development. Management Concepts is a Gold International Sponsor and an IIBA
Endorsed Education Provider For more information, visit www.managementconcepts.comor call
703 790-9595.
Agile
How to Scrum
How to bring scrum stakeholders, product owners and teams together to produce better backlog,
release and sprint results.
Scrum is about Teams producing complex

Results in an agile way. Scrum Teams achieve
results by using a simple framework and set of
rules. We will describe scrum to set the stage for
an applied approach to scrum.
The Team
The fundamental element of scrum is the Scrum
Team (or “Team”), which is a small (usually fewer
than ten) group of Team Members who provide
useful Results/Products for Stakeholders.
Arguably, the most important role involved in

scrum is the Stakeholder, as the Stakeholders are
the ones who have desires, wants, and needs,
and are the reason the Team is developing the
software in the first place. Often, there is a special
stakeholder called the Business Owner, who
actually controls the budget for the Team. The
Business Owner is often the one who called or
asked the team to form.
While the Stakeholders are the most important

source of validation for the project, the most
important person on the Scrum Team is the
Product Owner (PO). The Product Owner works
with the Stakeholders, represents their interests
to the Team, and is the sole Team Member held
accountable for the product the Team builds. The Product Owner must find a result that will
satisfy the Stakeholders needs and desires. The Product Owner provides direction and goals
for the Team, and prioritizes what will be done. The Product Owner connects the team with the
purpose.
The Scrum Team Members are the people that actually do the work that satisfies the goals
and priorities the Product Owner has set for them. Each Team Member is accountable to the
How to Scrum
rest of the Team for his/her performance, even as the Product Owner is accountable to the
Stakeholders for the Team’s performance. The Scrum Team is cross-functional; that is, people on
the Team (collectively) have all the skills necessary to do the work (analysis, design, code, test,
documentation, marketing plan, drawings whatever is required for the desired outcome). The
Team is self-organizing, self-managing, and constantly trying to improve itself. The Team works on
the priorities the Product Owner has set, and the Team commits to the amount of work it can do
without undue influence from the Product Owner.
In order to aid the Team in doing its work, there is a role on the Team called the Scrum Master
(SM). The SM’s responsibilities are to be a facilitator, moderator and coach, with particular
emphases on helping the Team mature its self-organization and self-management. The Scrum
Master manages the relationship between the Product Owner and the rest of the Team, and
facilitates removal of impediments for the Team – often working with the Product Owner, the
Business Owner, and other Stakeholders to do so. Impediments can come from within the team
and outside the team. The Scrum Master understands the scrum process and how the Team is
using it, recommends process improvements, and assures that the Team is following the process
they have agreed to.
The Backlog
A Scrum Team’s work is managed with a Product Backlog (“Backlog”), which is a prioritized list of
Product Backlog Items (“PBIs”, “Backlog Items”, or simply “Items”). When the list is small it is just
a simple list of things, as it grows we add grouping mechanisms to organize it and help us keep
track. The list of work items can evolve from a simple “cut the grass” to demanding “build a 20
story interactive office building”. The key is that the list of work items evolves and becomes no
more complicated than is necessary.
Agile
These Items represent the Stakeholder’s needs and wants – each of them is a request for
something of value to be provided by the Scrum Team. These requests can be for anything,
including software functionality, marketing, non-functional requirements, technical and
infrastructure requests, business support, maintenance of existing systems, and so on. It is a rule
of scrum that the Team shouldn’t do anything for any Stakeholder unless it’s on the Backlog. The
Team will be actively working on the top few items of the Backlog during the Sprint; this part of
the Backlog is called the Sprint Backlog, which is often thought of as a separate list of its own.
The Product Owner is responsible for prioritizing that backlog and the Team is responsible for
committing to as many Items they can do in a Sprint – thus creating the Sprint Backlog. From the
Team’s view, the Product Backlog is work that we might do some day and the Sprint Backlog is
work we are committed to doing.
The Backlog contains Items at all levels of fidelity, from vague wishes/wants/needs to finely
detailed requirements. The higher the priority of the Item, the more detailed the request should
be, so that it will be ready for planning and execution. Note: ready does not imply excessive detail
but, instead refers to enough detail. The team working with the PO will determine what “enough
detail” is. The key here is an unfolding dialog.
When a Scrum Project starts, the Product Owner should initiate the Backlog by working with
the Stakeholders and other Team Members and capturing their needs, wants, and requirements
as Backlog Items. As the Project progresses, the Product Owner and the Scrum Team should
continuously work with the Stakeholders to (re)prioritize the Backlog, identify new Backlog Items,
eliminate noise, refine and generally clean the items list to get it ready for planning. The project
effort will result in product that will often clarify and identify backlog items. This process is called
Backlog Grooming, and is a continuous process throughout the Project.
Now that we have the notion of the Backlog to work with, let’s describe the process, which
involves discussion of both Releases and Sprints.
The Release
The Goal of a Scrum Team working on a software project1 is to produce and release results that
meet the goals and priorities that have been set down by the Product Owner (hopefully as a
result of working with Stakeholders).
Typically, before a project formally begins2, there is a Visioning phase, when the Business Owner,
Product Owner, and the Stakeholders produce a Product Vision and a Product Roadmap. The
Vision provides the overall focus for the Project, while the Roadmap gives guidance about
Releases and their Goals.
The Scrum Team’s purpose is to create a result that satisfies the Stakeholders needs, wants and
desires, often so that more demand for their services is generated. This production is done
through a series of relatively short, fixed-length iterations, called sprints, in which results are
How to Scrum
produced by working on Items. The steps of a release are relatively simple, and I’ll describe them
here.
Usually, the first thing that happens in a release is Release Planning. The Stakeholders, the
Product Owner, and possibly other members of the Team, get together and negotiate what will
be accomplished in the Release. This negotiation takes the Product Vision and Roadmap into
account, balances the needs and wants of the Stakeholders against the abilities of the Scrum
Team, and the result is a set of Release Goals and a Release Strategy to achieve them. The Product
Owner and Team must update the Backlog so that there are prioritized Items on the Backlog that
support the Release Goals and Strategy and are ready for planning.
Once we have a Backlog that supports the Release Goals and Strategy, the team starts Sprinting.
The idea is for the team to do as many Sprints as the Release Strategy calls for, and then Release
the Results. Each Sprint looks basically the same, with the Release activities as part of the last one.
The Sprint
The fundamental process flow
of scrum is the Sprint, which
is a relatively short period of
time in which Backlog Items
are converted into Results. The
sprint is a regular rhythm of
deliver for the team and seeks
validation for the product from
outside the team. The sprint is an
opportunity to adjust.
The first thing to do in a Sprint
Agile
is Sprint Planning. In Sprint Planning the Product Owner works with the Team to negotiate what
Backlog Items the Team will commit to for the Sprint in order to support the Release Goals and
Strategy. Each of these Items has an agreed-upon definition of “Done”, and collectively these
Items are called the Team’s Sprint Backlog. It is the Scum Master’s responsibility to assure that
the Team commits to a realistic amount of work, and that the Product Owner does not unduly
influence this commitment. Often, the Items on the Sprint Backlog are tasked out in order to give
the team confidence that it can do the Item, and thus commit to it. The tasking of items can help
the team mature by paying attention to the work agreements they make with each other. The
tasking can also help the SM detect when the team is working well.
Once Sprint Planning is over, the team begins work in the Sprint. The team self-organizes to do
the work and self-manages as it does the work. The Teams work pattern is described as a swarm
to get the job done. Team swarm is a pattern of performing teams but, to an observer it looks like
a swarm. While the Sprint is in progress the Team will have Daily Meetings in order that each team
member understands what the Team’s status is. A daily standup meeting is for the team to orient
their day and focus on a combined effort. This allows the Team to detect when to adjust in order
to be as effective and efficient as possible. These adjustments often take significant time and
occur after the daily standup.
During the Daily Meeting, and continuously throughout the day, the Team Members notify the
Scrum Master of any impediments they encounter. It is the Scrum Master’s responsibility to
facilitate the removal of these impediments. Often, this requires working with Team Members, the
PO, the Business Owner, and other Stakeholders.
The Scrum Master must also ensure that the team does enough Backlog Grooming in order to be
prepared for the next Sprint’s planning meeting. The backlog grooming is a strategy to prepare
enough work to start on next so that a rhythmic flow of work can happen.
When the Sprint is over there is a Sprint Review, when the Product Owner and the Team show the
team’s Results to their Stakeholders. This is done for two reasons: to prove to the Stakeholders
that the Team is moving in the right direction, and so that the Team can get feedback on what
they’ve done. If necessary, the Release Goals, Release Strategy, and Backlog are updated as part of
the Review (or soon thereafter), taking into account the review and any “business reality” changes
the Stakeholders may have. When teams are small we can rely on more intuitive reasoning to
determine what the “right direction” is. As we grow we will see a need for more sophisticated
techniques that use metrics to help us us answer what the “right direction” is.
After the Sprint Review, the Team has an internal retrospective to analyze its performance and
process. The team decides what changes, if any, they wish to make to their process as a result of
this analysis. These changes will be “enforced” by the Scrum Master in future Sprints. To enforce
something the SM will need to shift the attention to the issue at hand. Energy follows attention,
let the team react. Telling the team what to do is not desirable. Shifting the team focus and
How to Scrum
thereby enforcing change is an art of the SM.
At this point the Sprint is complete, and the team either begins the next Sprint, the next Release,
the next Project, or disbands, as appropriate.
Quick Summary
Team 7±2 does the work
PO provides the work requests
SM provides care for the whole team (PO/Team)
Team swarms on the work
Team is cross functional
Team owns its process
PO provides validation for each work request
Work is done in short bursts < 30 days each (Sprints)
Work starts and stops with Planning and Review
Review demo for product; Review retro for process
Daily standup detects any adjustments needed
PO determines priority as a flow of work requests
SM observes and helps the whole team adjust
SM tunes the whole team for maximum performance
References
1. Maintenance Teams can also use scrum, but their scrum usually only contains Sprints, and
not Releases.
2. The Visioning Phase can also be the first phase of a project, it can go either way.
About the Authors

Dan Rawsthorne has worked in software for more than 25 years in many
capacities, from coder to product/project manager. He has worked small (3
people working on an e-commerce web site) and large (500 people working on
aircraft avionics) projects, and has learned many things about what works and
what doesn’t. He has worked in small “hack it out” companies and big CMM and
ISO organizations and has been involved in process improvement in most of
them.
Dan is a transformation agent who helps organizations change themselves through application
Agile
of common sense and agile techniques. His formal training (PhD in mathematics) guides him to
look for underlying problems rather than focus on surface symptoms; his military background
(retired reserve officer) helps him understand the importance of teamwork and empowerment;
and his common sense tells him that change must happen in small manageable bites. Dan is
capturing his approach to scrum topics.
Dan is a Certified Scrum Trainer with knowledge of many software processes, procedures, and
techniques, and brings them all to bear on the problems he sees. He is a firm believer in agility,
having been introduced to eXtreme Programming (XP) by Kent Beck in 1995, and to scrum
by Linda Rising soon after. It was these experiences that led him to move from government
contracting to become a coach, trainer, and consultant.
Douglas E. Shimp has 18 years of experience in the technology field and has
played key roles in software development (developer, QA, Analyst, Manager,
Leader, Coach and Consultant etc). Doug whose passion is about teams and
applied learning for real product development is establishing himself as a
leader in this area. He believes that the core bases for applied agile is that
“You must see the result for it to be real; otherwise it is all just theory to the
individual”. He is actively writing a book on Scrum Topics.
One of Doug’s distinctions is his focus on the interaction of technology and corporate cultural
issues. He is an active writer on numerous blogs and a regular speaker at conferences (you can
often find Doug at one of our events). He has taken his passion for bending technology to help
people better communicate. Doug is actively using his passion to improve technology and
people interactions. He has establish both in person and online communities and regularly
fosters social networks where individuals and companies can build better reputations.
Doug is a Certified Scrum Trainer with the Scrum Alliance and a Trained Facilitator with Innovation
Games.™
Agile Transformation Guidelines: Avoiding Pitfalls

Ask the right questions and follow these key steps to transform to Agile painlessly. Learn how to
revolutionize your development practices from an experienced Agile transformation coach.
Being an Agile transformation coach since 2001

at IBM and other companies has taught me a lot
about being agile; especially the art of change.
Increasing a corporate agile community from
300 to over 3,400, teaching two day courses to
over 1,050 people, and consulting with teams
were not the only ways I discovered the essence
of “being” agile. Leading and coding with my
agile team was just as wonderfully painful and
educational.
Here is an eight point checklist that will help you save time and avoid common pitfalls in agile
transformation.
Be Type Aware
One’s a Maverick, Two’s a Team
Get Executive Cover
Expect the Change Curve
Lead with Pain
Tool Up
Create visibility
Don’t Dictate – Facilitate
Be Type Aware
The Myers-Briggs Type Indicator (MBTI™) is used to help individuals understand their preferred
ways of working, and to help teams appreciate diverse viewpoints. It lets people discover their
most comfortable ways of working. For example, some people refresh your energy by being
with other people, and others prefer to read a book alone. Some learn about their environment
through models, and some with data. Some decide issues based on impact to people, and some
prefer more detached logic. And some prefer spontaneous adaptation versus well laid out plans.
Unnecessary friction can develop on the team without appreciation that people may differ not
just in technical skill, but also in temperament and working style. This is especially true during
the stress of process change. Educating the team in the different styles of workers up front and
respecting the differences will side step this pitfall. MBTI™ has served many teams well, but other
Agile
similar tools are available.
One’s a Maverick, Two is a Team

An agile evangelist on the team can’t work alone. The can be viewed as an outlier. When two
people embrace a targeted practice on your team, they support each other, but also publicly
show unity of support for the practice. Getting at least two champions on the team for agile
transformation gets people to herald its adoption and the reverse is true. A change with only one
champion often never comes to fruition.
Get Executive Cover

Change feels threatening to people who are talented in their previous ways of working. They are
vested in skills they have developed, and their success as led them to leadership positions. Show
them that the addition of agile practices can add fresh tools to their pallet of skills. And most
importantly, get buy-in from upper management to support the change initiative.
Expect the Change Curve

Agile will make you more productive. Some organizations may be tempted to mark teams Agile,
then reduce their staff due to expected increases in efficiency. This is a trap at the beginning.
The Process Change Model by Virgina Satir [1] says that we will first encounter resistance and less
productive chaos. Benefits will come, but the cost of agile transformation will counter balance
the benefits while you are getting started. You have to invest before you see the gain.
Lead with Pain

Instead of announcing the team will be doing a new practice, star by discussion the pain points
that make the practices useful. For example, say “We seem to lose a lot when people leave the
team”. This may highlight the need for pair programming with rotating combinations. “Sometimes
people don’t like what we’ve built, even after careful specification”. The practice of using feedback
from iteration demos will become attractive. Showing the problem and need, then bridging to
selected approaches eases the team’s changes.
Tool Up
Spreadsheets and index cards are useful for learning agile concepts and are easy to work with,
but using a tool designed for agile project management like VersionOne, RallyDev, or AgileZen
helps guide new teams through the process. Moreover, it shows skeptics that there is a long
history of industry investment. Introduction of tools specifically designed for an agile process is
usually a pivotal moment of change.
Create Visibility:
Agile shines when the whole team can understand the flow of work, and pitch in to help or
identify problems. Your selected agile project management tool can help, and physical artifacts
can supplement these. You’ve succeeded if team members know not just the status of their
work, but have an idea of the workflow of the team as well. Artifacts for this can include Scrum’s
burn down chart, the taskboard or Kanban board, build and test success lights for continuous
integration
Don’t dictate – Facilitate

There are variety of good assessment surveys for your teams retrospectives or lessons learned,
such as the Shodan Adherence Survey [2], the Agile Evaluation Framework, [3], Comparative
Agility(tm) Assessment [4], and the Sidky Agile Measurement Index (SAMI) [5], IBM Rational Self
Check for Software Teams [6], and Dean Leffingwell’s Agile Process Metrics [7]. They rate questions
numerically to view the team’s deployment level of given practices. This gives people a head start
on a solid combination of practices.
But counter intuitively, there is also a niche for placing the work of authoring questions, targeting
towards measuring their progress with “being” agile on the team members. This engages another
section of their brain. They can bring their unique perspective on observed problems, and key
practices into the instrument. Numerical assessments of teams can rotate between a repeated
standard list of questions, one of several alternate sets for variety, non numeric retrospective
techniques as described by Derby and Larsen in “Agile Retrospectives” [8]. Try also adding a
session for an iteration’s retrospective where the team constructs six questions. The act of
choosing the top 6 and wording the questions can be a key learning moment. The coach can cue
the team by suggesting they consider practices in the following key areas: requirements analysis,
workflow management, building quality, and process optimization. Within that framework,
people should engage their experience to choose fresh questions. The exercise of considering
these can be as valuable as the questions and data themselves.
This approach gives you the best benefits of each technique. You get historical trend data, variety
to explore fresh questions on alternate iterations, non numeric methods, expert thought using
pre-crafted questions and best of all, team buy in and enthusiasm for the questions they have
developed. Learning from the experts is good, but sparking the learner’s analysis of what they
would ask is equally powerful.
The coach’s role is to help the team create their questions. The coach can guide the team in
considering some key areas, such as what practices they feel are key for quality, or what practices
they feel are key for requirements. The coach can also warn the team of known pitfalls in terms
of which wordings or practices may not work. But the coach also needs to be open minded. The
goal is not to lead the team to a particular answer, but to enable the team’s creation of a question
Agile
set that works for them in use, and teaches them in the process of its creation.
This example shows questions that were developed not by a consultant, but by a team beginning
their agile journey. Having them write the questions serves as a great way for coaches to glean
the team understands the core principles. Longer consultant generated surveys are still fine, but
these team generated ones give you a view of what’s inside the mind of the team.
Practice Explanation Level

Scrum Meetings Do you hold short daily planning meetings that highlight
what each person did yesterday, today, and blockers?
Prioritization Does your team continuously review the business value of
your requirements?
Velocity Does your team observe their actual rate of progress, and
update their plans?
Estimating Does your team provide estimates focused on relative size
and complexity?
Communication Does your team communicate with the right people at the
right time, and show visible progress of the project?
References
Virginia Satir. Satir Change Model. http://www.satirworkshops.com/files/satirchangemodel.
pdf
William Krebs. “Turning the Knobs: A Coaching Pattern for XP through Agile Metrics”. Springer,
2002
Laurie Williams, William Krebs, Lucas Layman, and Annie I. Anton, “Toward a Framework
for Evaluating Extreme Programming,” Proceedings of the 8th International Conference on
Empirical Assessment in Software Engineering (EASE ‘04), Edinburgh, Scotland, May 24-25,
2004, pp. 11-20.
Mike Cohn. “Succeeding with Agile”. Addison-Wesley, 2009. Also online at comparitiveagility.
com by Mike Cohn and Kenny Rubin.
Ahmed Sidky and James Arthur. “A Disciplined Approach to Adopting Agile Practices: The
Agile Adoption Framework”. Agile journal, June 2007. Also see “Becoming Agile” by Greg Smith
and Ahmed Sidky. Manning 2009
Per Kroll, William Krebs. “Introducing IBM Rational Self Check for Software Teams”.
developerWorks ®
Dean Leffingwell. “Scaling Software Agility” Addisson-Wesley 2007.
Ester Derby and Diana Larsen. “Agile Retrospectives”. The Pragmatic Programmers, 2006.
MBTI is a trademark of the Myers-Briggs Type Indicator Trust
IBM is a trademark of the IBM Corporation.
developerWorks is a Trademark of the IBM Corporation.
Learn more: see VersionOne.com, Rallydev.com, and AgileZen.com for more details the tools
mentioned.
About the Author

“AgileBill” Krebs has worked as a developer and agile coach at five IBM labs since 1983. Since 2001,
he’s used and taught Agile methods worldwide, teaching over 50 classes to 1,000 engineers and
managers. He’s presented at agile conferences, IBM Research, the IBM Academy of Technology
conference on Agile. He holds two certifications in Scrum, one in MBTI is completing a certificate
in virtual worlds in 2010. Currently he teaches with Davisbase LLC, and is the founder of Agile
Dimensions LLC where he specializes in efficiencies using immersive virtual environments. Bill
is also a member of the Scrum and Agile Alliances in addition to his local Agile RTP user group.
Find Bill on LinkedIn, agiledimensions.com, or the worldwide Agile 3d (http://www.meetup.com/
agile3d) user group.
Agile
Managing Customer Expectations in IT

Outsourcing
Each industry has its own unique challenges
to fulfill what the customer expects. Here are
some general rules you can follow for successful
customer expectations management in IT
outsourcing.
In today’s market, customer expectations are

frequently discussed. Everyone talks about
them, and everyone claims their company
takes care of them. The awareness is evident,
but there are many customer expectation
misunderstandings due to:
No formal, defined process for customer expectations management (CEM)

No industry standards or best practices defined for CEM
No classification for unique customer expectation sub-topics (CRM, issue/feedback tracking,
partnership development, CSAT, customer service, etc.)
No customer expectations management specialization, (e.g. CEM for IT service providers, CEM
for manufacturers, etc.)
Although each industry has its own unique challenges, there are some general rules you can
follow for successful customer expectation management. First let’s define expectation.
What Are Customer Expectations?

Expectations are your customer’s vision of a future state, result or action. These are usually
unstated, but are critical to success. Expectations can fall into two categories:
1. A primary measure of success

2. Drive all of your client’s actions and decisions
Typically, your customers are satisfied when you come very close to their expectations. This can
apply to both processes and results. In fact, customers will have expectations about both, and
expectations have different sources.
Key Customer Expectation Sources
Managing Customer Expectations in IT Outsourcing
Personal and Company Needs

People differ in their needs and motives. What is important for one is irrelevant for the other. For
example, for some clients it is very important to be constantly informed by the project manager
(PM) about status changes, while others will find this unimportant.
Previous Experience
First-time car buyers may have only one expectation – the car will drive. Over time, however,
those expectations grow into new expectations regarding comfort, security and many other
things. With experience, customer demands for professional competency and its value grow.
References
Personal references or referrals about products/services unfamiliar to the customer are important.
Buyers are influenced by those they know, as well as strangers.
Promises made by the company

Many feature, pricing, service level and support promises are made during marketing campaigns
and pre-sales phases. Numerous expectations are formed during these times. Messaging in
advertisements and web-site/internet resources can also influence what clients expect of you.
Expectations Can Take Different Forms
Desired Level
Expectations need to conform to initial clients wishes. The desired level depends on the client’s
background. For example, the expectations of a person who lives in a castle differ from the
expectations of a person who lives in a flat. It’s important to know that cultural differences and
expectations play a significant role when outsourcing to foreign countries.
Ideal Level
Clients are most satisfied when their expectations hit an ideal level where an acceptable price is
matched with the highest level of service. The notion of “best service,” however, is unique to each
individual customer.
Typical Level
A typical or common level of service is understood when the product or service is well known. For
example, people know exactly what to expect when they order “fast food.”
Agile
Minimum Acceptable Level

Minimum service level expectations are often linked to price. For example, a clean bed might be a
minimal expectation for a low-priced hotel room. The customer might forgo the TV and mini-bar
in order to save money.
You need to understand client expectations in order to meet desired service levels. At the same
time, expectations are dynamic and may change over the time. Things change as collaboration
progresses and specific situations change (what was ideal yesterday, might not be acceptable
today).
Expectations Come From Different Sources

In the software development business, the typical customer is usually a company looking for
an outsourcing vendor/partner. It’s not a specific individual who has expectations that need
to be managed in order to succeed. The “company” is a stakeholder list with a hierarchical
structure and internal corporate politics that need to be taken into account. For example, project
manager expectations differ from CIO and CEO expectations. People within the company
have different levels of influence that also need to be considered. It would be nice if all the
customer stakeholder expectations were the same, but that’s not the case. Your job is to examine
discrepancies and figure out if there’s a way to make everyone happy. Alternately, you can
determine which individual expectations are most important to your project’s success.
This is why we recommend the following ongoing CEM framework:
Customer Expectations Management Process
Analyze
Identify your stakeholders from the customer side. List all the contacts you have and those you
want to acquire in future. List all the positions, based on the customer’s organization chart,
of your stakeholders and assign roles and influences. Identify your champions and those that
oppose you and understand their motives.
When you begin negotiations with your new customer, it’s easy to obtain detailed information. At
this stage, people are very open to expressing their expectations. The only thing you need to do is
ask. The service provider may identify contradictory expectations from different stakeholders and
these should be prioritized and examined closely.
Set
After you’ve analyzed and clarified customer’s expectations, it’s time to align them with yours by
setting expectations for the services you will provide. You need to build the right management
Managing Customer Expectations in IT Outsourcing
hierarchy, and escalation and communication schemes to reflect the client’s management.
In addition, the project manager should align the team structure and team work, prioritizing
expected result areas and building the right Software Development Lifecycle (SDLC) processes.
When dealing with offshore outsourcing, you’ll need to identify cultural differences and provide
special training to better align teams and collaboration expectations.
All these critical steps and actions should be covered early on – during a stabilization and
collaboration phase. It’s best to take care of these requirements before the actual project starts.
Manage
When the project starts, you’ll need to manage expectations dynamically, because they will
change as the project moves from one stage to another. As you achieve results and pass project
milestones, you need to periodically check expectations and synchronize new developments with
new expected results and actions.
…And Analyze Again

At some point you’ll need to analyze expectations again. You may have several triggers that re-
initiate the ANALYZE phase such as:
Organizational changes on either side of the table

Stakeholder lists may change
Completed milestones might trigger new analysis (i.e., contract re-negotiations, new service
releases, new opportunities, new product lines, etc.)
Conclusion
Good customer expectation management requires your commitment. This is a process that needs
ownership. You have to identify the person(s) within your that company should analyze, set and
manage expectations. This could be same person who builds the partnership with the client (i.e.,
client partner, project manager, etc.). They may track expectations as additional items within
CRM systems, project plans, risk management plans or any other document/tool that is actively
used and maintained. You could also organize a team that manages all expectations within the
company (audit or consulting teams).
Keep in mind that customer expectations are continuously evolving. Improvements and re-
alignments will lead to a higher quality of customer service. Improvement should be tracked by
cutting-edge methodologies, better SDLC processes, industry certification standards and most
of all specific customer feedback. Remember that your most unsatisfied customers are the most
valuable source for improvements. They help you and your organization grow professionally and
they help you exceed customer expectations in the future.
Agile
About the Authors

Serhiy Kharytonov is the EVP, Consulting Services, and Khrystyna Kosyk is the Engagement
Director, at SoftServe, a leading global provider of proven high quality software development,
testing, and consulting services.
Outsourcing is Not a Slam Dunk

Outsourcing requires explicit documentation and communication methods. Learn how to plan
outsourcing projects, select the right partner, and govern the relationship.
Outsourcing Overview
In today’s business climate, companies are
looking to other parts of the world to leverage
talent, infrastructure, innovation, and agility
– in addition to more attractive personnel
costs. After all, technology has enabled this
globalization, and further, technology has
helped to erase any sense of geographic
distance among both people and industry. In
fact, the practice of outsourcing has infiltrated
every facet of business, and some of the largest
companies in the world rely on outsourced partners to deliver complex and critical services
and products for customers and the companies themselves. While many businesses have been
able to reap the rewards of outsourcing, other companies have experienced the heartache and
disappointment of outsourced projects that have ended poorly.
While outsourcing may be the answer to many organizational challenges, outsourcing is not – by
all means – a sure-fire solution. Outsourcing is a venture that cannot be taken lightly as it requires
investigation, diligence, governance and refinement. Outsourcing involves a commitment,
not only in the initial stages, but through the entire lifecycle. Thus, in order for outsourcing to
succeed, a company must have a clear plan, select the right partner, and govern the relationship
with very explicit documentation and communication. When executed properly, outsourcing can
generate tremendous success on a number of levels, and it can most certainly allow businesses to
extend capabilities and profit.
That said, at a high level, outsourcing poses a challenging predicament. Outsourcing requires
an organization to select a company from a sea of many unfamiliar vendors, and to entrust the
chosen company with processes or products that may be critical to that particular business. The
outsource partner may be continents away, may never be seen face to face, and may not even
share a common language with your organization. Also, to complicate matters, your outsource
partner may know nothing of your business or of the clients the outsourcing company is
proposing to help serve. As a whole, this situation can make for a very tenuous arrangement
that can be steeped in anxiety and uncertainty. The key to success with outsourcing then is
to overcome these gaps and build a foundation of understanding and explicit expectation.
Agile
Establishing a clear objective that outsourcing will serve for your business is a great beginning to
this process.
The Drivers of Outsourcing

Since the reasons vary greatly from company to company, it is extremely important to understand
the factors that may motivate a company to consider outsourcing. Identifying why your particular
organization should outsource will also help to bring a focus to the endeavor, and it may also
help to develop an underlying corporate objective that your organization can work towards.
Agility and Efficiency

Working with outsource partners means that your organization will gain access to specialized
skills when these skills are most needed. This on-demand labour model can give companies
increased agility and speed to market, without the persistent overhead costs of often
underutilized internal employees. Moreover, reducing the under-allocation of salaried staff
directly increases the efficiency and profit margin of a business. Additionally, outsourcing allows
the internal resources of an organization to focus on other pressing business needs – in turn
potentially allowing multiple critical projects to be executed concurrently.
A lack of internal skills or infrastructure

Most companies are continuously seeking new sources of business and revenue, which means
new opportunities are very rarely ignored, even if these opportunities may fall outside the core
competencies of the organization. After all, if a business cannot meet a need in the market, a
competitor will identify a way to meet this need, and leave the pack behind. In order to keep
up with the competition, businesses must continuously evolve through ongoing research,
development, learning and growth. This cycle can be very expensive, and when the skills and
infrastructure a company requires exist within another organization, a case for outsourcing exists.
Leveraging the experience and skills of an external company without having to invest in learning
or the development of new infrastructure is a major driver of outsourcing.
Costs
The overhead associated in keeping a business running can often make providing specific
services and products cost-prohibitive. This situation can be particularly true in unstable and
changing markets that push prices beyond what the market is able to bear. Reduced labour
or material costs in other geographic locations, however, can allow a company to continue
to provide the same services and products – more effectively – at a competitive rate. Note:
Outsourced projects typically require an increased allocation of internal Project Management
time. Therefore, you should factor these costs into the budget of any outsourced project.
Business development opportunities

Forging relationships with companies that can support your business can also result in
opportunities to reciprocate referred business. If your outsource partner is located in a different
part of the world, that company may be able to introduce you to an entirely new market – along
with a complete new set of clients. Explore the possibilities that exist and talk to your partner
about how you can help each other grow your respective businesses.
Thus, there are many compelling reasons why outsourcing may be the right solution for an
organization. However, your organization should not pursue outsourcing blindly. Understanding
why outsourcing can be the right choice for your company will help to reinforce your outsourcing
decision when challenges may arise. That said, you should have conviction in your outsource
model – and remember that commitment is paramount to long-term gains.
How To Get Started

Once an organization has determined that outsourcing is an appropriate approach for the
business, it is time to begin the process of building an outsource model. The first step will be to
identify the best partner-based on the specific organizational needs. Ultimately, the partner will
play a major role in the overall success of the model; thus, extreme diligence must be dedicated
to this process. While selecting the right outsource partner can be a daunting task, there are key
criteria that will help to maximize the potential for success.
Write a good RFP

Good outsourcing is rooted in clear communication, and your first touch point with a prospective
vendor should be a request for proposal. This document is an opportunity to demonstrate
business savvy, and to set the bar for quality, professionalism, and protocol. Sadly, I cannot count
how many RFPs I have read cover to cover – only to wonder what the party is actually seeking!
Thus, remember to be as clear as possible about what you expect from your vendor. The RFP
process should not be a game of decryption – testing respondents on their ability to comprehend
a convoluted document. You should use language that is appropriate to the services you are
seeking. Be explicit and thorough. If you are issuing the RFP internationally or overseas, identify
the language skills you expect your vendor to possess – as well as the response times and time
zones the vendor must work to service.
Do your research
The international market is flooded with companies claiming to have capabilities in every aspect
of business outsourcing. While these claims may not be made with malicious intent, realize that
many companies are hungry to get a piece of the pie, and will overstate experience and skill-
set to win your business. Ask for examples of their work, speak to some of their other clients,
Agile
and always request a detailed breakdown of their own workflow process and contact strategy.
Remember to ask questions such as how does the company ensure quality? What infrastructure
exists within their organization to ensure connectivity, up-time, security and reliability? Who do
they employ, what are their on-staff skills, and what are their contingency plans for employee
attrition? How often will the company communicate with you and what documentation can you
expect to track their work? What is the time difference – and who will respond to after-hours
emergencies? If they cannot immediately respond to these questions, consider that the company
may not have the experience needed to uphold a successful outsource arrangement with an
overseas client.
Consider the differences among international talent

Professionals who are experienced working with outsource partners speak to the variances in
work style and competencies based on location. Comparing India to Ukraine, for example, reveals
some fundamental differences in outsourcing experiences. For instance, Elizabeth Cooper, the
CEO and founder of Intelligent Pipeline Inspection Gauge (iPIG LLC), a California-based dedicated
service for the oil and gas industry, needed help with technical aspects of her work. Specifically,
she needed help debugging the highly technical software that analyzes the risks of oil pipelines
and vessels, and in making improvements to this software’s overly technical interface. Working
with Ukraine-based SoftServe, she found the high level of mathematical expertise of these
programmers invaluable.
“The ability to deal with highly computational software with long derivative algorithms was
essential to the project’s success,” says Cooper. “The Ukrainian developers we worked with had
true mathematical expertise, not just with software. This enabled them to demonstrate after they
debugged the software they had left the mathematical algorithms intact. We couldn’t have done
it otherwise.”
Wade Person, the Director of Software Development at a Fortune 500 company, also noticed the
differences of working with outsourcing companies in different countries:
“My experience with the Indian companies I worked with was that they would always do exactly
what you wanted them to do, no more, no less. What I really appreciated about SoftServe,
the Ukrainian company I worked with was their level of involvement, sense of ownership, and
willingness to make suggestions. We would give them directions on how to do a certain feature
and they would sometimes come up with a better way to do it. They were always very open and
tactful. With the Ukrainian company I felt that we were much more on the same wavelength.”
Selecting the right partner is a key factor in outsourcing success; consequently, the process
should not be rushed. Always remember that outsourcing is about long-term value. Thus, you
should look for a company that you like, and that could grow with your needs over time.
Staying On Track
Governance and relationship management are fundamental essentials if any success is to be had
from a long-term outsourcing arrangement. As is customary with internal staff, your extended
(outsourced) staff must be evaluated and monitored for consistent performance. In fact, this
situation becomes even more important with a team that is geographically distant. To achieve a
true partnership, however, an organization should never manage an outsource vendor harshly.
The quality of the relationship will affect the outcome of the work a partner produces. The partner
must feel integral to the business – and not like hired help whose efforts can be replaceable at
the slightest hiccup. You should also cultivate trust through professionalism – in other words,
you should treat your overseas partner the way you would treat a local associate. That said, you
should also have solid agreements in place to rely on if the arrangement turns sour.
Demand a thorough service level agreement

At the end of the day, regardless of the service that you thought you were getting, or what
type of service the vendor thought that you wanted, the only item that really counts is what is
written down on paper! The SLA must detail the guidelines of the entire working relationship.
For instance, what are the assurances of quality and the standards that must be met? What is the
availability of the outsource team and how will they respond in situation-critical times? How will
they pass back the intellectual property they develop over time that may not exist within your
own organization? Service level agreements must be negotiated so that the interests of both
parties are satisfied. Do not be pressured or rushed into signing a long-term commitment until
the SLA has been approved.
Give your outsource team context

Outsourcing is a two-way street where both parties must work towards being good partners
with one another. Moreover, for the success of your partnership, it is vital that you are completely
transparent with your partner. Once a team is brought on-board to provide outsourcing services,
they must be considered as an extension of your organization. Providing this new team with
as much background information as possible helps to clarify the end deliverable – and paints a
picture that describes exactly how their contribution will impact the success of your business.
Engaging your outsource team with the details of a project builds a sense of association and
contribution – and your partner will appreciate seeing ‘the bigger picture’.
Recognize the need for strong Project Management

Regardless of what other recommendations you choose to follow, dedicating a Project Manager
to govern the day-to-day relationship is the single most imperative rule of successful outsourcing.
The Project Manager will craft detailed project specifications, develop a strong relationship
with your partner, and will monitor progress closely enough so that potential challenges can be
Agile
identified and resolved before having any major impact. As the geographic distance can make
outsourcing very challenging to the service provider, a dedicated point of contact that the service
provider can communicate with when needed is extremely helpful – and will only reinforce a
sense of teamwork and foster commitment to your business.
Make quality the end goal for all

The internal Project Manager must state and reiterate that the goal of the outsource relationship
is the quality of the end product or service. Cost savings and other benefits should never
overshadow the need for absolute quality, or your vendor will shift the focus to speed. Losing
quality in a vendor – who is across the globe – creates an immediate sense of powerlessness and
fear, and will quickly erode the profitability of the partnership. Thus, above all else, quality must
be positioned as the collective goal.
Establish a contact strategy

Be explicit about how often will you speak with your vendor. Identify what days you will
communicate, and what the purpose of each exchange will be. Do not let the project get away
from you. Stay in close contact with your vendor – participate in the project and everyone will
feel more of a responsibility to one another.
Commit to it
One of the classic fatal errors any organization can make is not fully committing to a project.
Own it – understand it – and stay on top of it. If you do not have the time or know-how, hire
a reputable, specialized outsource management group. These groups exist to help select
an appropriate vendor, or to manage the outsource process to a vendor the group will be
responsible for. Make sure that they have the experience and that the group will stand behind the
work of the vendor the group chooses to conduct business with.
Learn from it
Whether the project was a smashing success, or an unfortunate failure, consider why the situation
occurred. Discuss the project with your vendor and your colleagues to determine if you would
change anything during future dealings. Ideally, you should conduct a post-mortem – where all
of the involved parties are given an opportunity to discuss the project frankly. Document the
changes you agree to make, and ensure that the Project Manager incorporates the revisions to
the process in any future projects.
Understanding The Risks

While outsourcing can obviously provide many benefits, this method does not come without risk.
Outsourcing has created a modern-day gold rush, where every company, big and small, is looking
for ways to cash in. Being aware of what can go wrong is critical to ensuring that the outsourcing
model is well-developed and that the risks are minimized.
Lost IP
Over time, your outsourced team will come to learn the facets of your business intimately –
perhaps even at a deeper level than your internal employees. This relationship is a natural side-
effect of outsourcing, but it is important that any new intellectual property that is captured by
the outsource partner will be transferred back to the organization. How this knowledge sharing
takes place largely depends on the type of work that is being conducted, but written reports and
ongoing status updates are two effective ways of ensuring that knowledge is documented by the
outsource partner.
Poor quality
A lack of quality is probably the most-reported issue when it comes to outsourcing. The problem
may occur because of varying standards, a lack of clarity regarding what was expected, and
sometimes, an incompetent vendor. For all these reasons, a thorough review of progress must
be conducted very soon after engaging with an outsourced partner. Do not allow a significant
amount of time to pass before requesting to see the end product. Get your vendor accustomed to
these check-ins, do the check-ins frequently, and do them consistently. If issues with quality arise,
work with your vendor to determine an appropriate solution. Engaging the extended team in
making improvements will shift responsibility for better work to the outsourced team.
Unexpected surge in internal Project Management time

Outsourcing projects requires more Project Management time than if the work was completed
internally. Remote teams require more communication and status reporting; thus, the Project
Management role will see an increased allocation of time spent on outsourced projects. Ensure
that the bandwidth exists internally to manage such projects, and budget for these projects
accordingly. A good rule of thumb is to allocate an additional five to ten percent Project
Management time over what is typically budgeted for internally-executed projects.
Overall then, geography should not limit the potential of your business. International talent
offers alternative means to deliver products and services –- rapidly and cost effectively – without
compromising quality. In the current economy, outsourcing is not only viable; it is often needed
to maintain a competitive edge. If you have not yet tried outsourcing, expect a steep learning
curve for the initial six months. As with any other new business practice, learning how to navigate
unfamiliar territory can be intimidating and very challenging. Outsourcing is a strategy that can
bring long-term gain; consequently maintaining a commitment over time will see your company
overcoming many initial issues and enjoying the ever expanding opportunities on the horizon.
Agile
About the Author

Gina Lijoi has worked in the online space for the past 10 years, originally focused on Project
Management, and more recently, operational and functional efficiencies. Gina has managed
hundreds of client initiatives, focusing on verticals including pharmaceutical and healthcare,
consumer packaged goods, media and entertainment, and travel. She has acted as a consultant
and contributor to multiple international Project Management websites and print publications.
Software Development Outsourcing: Get Control of Cultural Differences
Software Development Outsourcing: Get Control

of Cultural Differences
Illuminating the differences between cultural mindsets helps companies improve the success of their
software development outsourcing strategies.
Introduction
Outsourcing IT and software development is

becoming commonplace. After all, there are
numerous advantages including lower costs,
additional expert resources, faster product
development, faster time to market, and flexible
human resource allocation.
However, there are unobvious differences

in work methods and habits due to varied
cultural ways of perceiving and relating to
events and people. Accommodating these differences can significantly influence the building of
productive relationships and make outsourcing a smoother process. For example, China, India
and the Philippines engage in a process-oriented culture wherein the main focus is on structured
processes and well-defined instructions. Work proceeds comfortably in Waterfall and V-model
processes. On the other hand, a more dynamic Eastern European culture is closer to Western
tradition which tends to accept flexibility and pro-activeness using Agile methodologies and
direct communication.
Why does this occur? And what are additional obstacles besides the obvious technical issues?
Barriers to Communication among Different Cultures

When a company decides to outsource work, it usually chooses to work with an organization
of a different culture. ‘Culture’ is defined as a complex set of values, behaviors, and beliefs that
are shared by a specific group of individuals. Each cultural group expresses authority, creativity,
accountability and other values in different ways.
Here are some obvious common barriers to communication with other cultures:
Language
General Education Level
Time Difference
Nationality Specific Traits
Agile
Religious Beliefs
Gender Roles
Individual Personal Space and Behavior
Culture specific differences influence collaborations in a huge way. The following paragraphs
enumerate some common criteria to evaluate differences which are important to take into
consideration when outsourcing offshore.
Low-Context and High-Context Cultures/Direct and Indirect

Communication
Low-context and high-context means the manner by which communication occurs and the way
information is presented.
Low-context: (e.g. Germanic, Scandinavian, and Anglo)
Usually written out in a full, concise, direct manner with numerous dependencies.
Focus is on specific money figures and deal closing.
Can cause specification and reporting misunderstandings.
High-context: (e.g. Japanese, China, Indian, most Asian and French)
Less information detail.

More emphasis upon reputation.
Confrontations are minimized.
More value is placed on politeness than clarity.
High-context cultures may interpret low-context cultures as being aggressive, whereas low
context cultures may perceive people from high context ones as being overly secretive.
Polychronic vs. Monochronic Cultures (multi-tasking abilities).

Polychronic:
Tend to multi-task.
Open-door policies.
Take calls in meetings.
Typical USA.
Monochronic:
Focus on one task at a time.
Sense of orderliness.
Not fond of interruption.

Pride in a sense of orderliness.
Typical German (e.g. may be offended that an American is taking a phone call while in a
meeting).
Past, Present and Future Orientation Cultures

Past-oriented societies:
Tend to be conservative.
Relate to a more traditional way of doing things.
Long historical traditions include Britain, China and Japan.
Present-oriented societies:
Prefer short-term benefits

See the future as an uncertain place.
Past as past.
Examples: Many Spanish-speaking - Latin American countries, Philippines, Sri Lanka.
Future-oriented societies:
Emphasis and optimism on the future.

Believe that they can have a positive effect on their future.
Young nations and the United States are good examples of future-oriented societies.
Individualist vs. Collectivist Cultures

Individualist:
Value self-determination, initiative, independence, and uniqueness. (Western)

Work generally assigned to one individual.
Collectivist:
Work, comply, and identify well with groups that look after them. (Asian)
Consensus is required.
Tasks are generally assigned to group (usually takes longer).
Time Perception
Western cultures:
Agile
Time is being used up and cannot be replaced.

Time is money.’
Punctuality and deadlines are valued.
Non-Western:
Time is plentiful.
Punctuality, deadlines not important.
High and Low Power Distance Societies

High power distance:
Boss is always “right” (even when wrong)

Asian and Russian
Low power distance:
Both employees and managers on a more equal level

United States and Northern Europe
Cultural Differences in the Software Development Process and

Communication
With respect to software development, these cultural differences may cause problems among
culturally dispersed team members. Those who don’t have this experience should closely
collaborate on daily basis. For example, American software development companies approach
time differently from a relationship-oriented culture such as India. Indian workers prefer to spend
more time with the American workers in order to better know each other. Individuals from time-
limited societies in turn do not take time to develop trust and relationships and instead rely on
legal systems to handle these problems. In cultures where time is plentiful, like Latin America,
Asia or India, making a person wait is common. An American team prefers to handle the tasks
at hand quicker that their counterparts from India. As a result, both groups of people may gain
negative impressions of each another – and this type of misinterpretation can hinder work down
the line.
Other potential differences that cause misunderstandings during the software development
process include a culture’s interpretation of hierarchy, deadlines, and product quality. Further,
language barriers can result in misinterpretations and cause project delays. With respect to the
actual software development product, cultural developments can surface as well. For example,
one type of user interface may be acceptable in one culture but not another. Western result-
oriented professional behavior can cause conflict in China’s process-orientated culture, where
result is treated as a “death” and process itself as a “life”.
How to Minimize Problems Caused by Cultural Differences

Companies should consider the proper expectations from the start and be ready to confront
differences with other cultures. Further, instead of being conflicted with these issues, companies
should understand the root cause of these differences and work through these “bumps.” That said,
there are ways to avoid or minimize problems caused by cultural differences.
To minimize problems, organizations should:
Take part in intercultural training. Learning about the culture and mindset of the organization
that you are working with can work wonders when it comes to improving the working
relationship. Further, learning about the culture develops cultural empathy and the capability
to solve potential intercultural problems.
Work towards finding cultural common ground. By doing so, both cultures can build
relationships and build upon the strengths of each culture as well.
Let the IT manager responsible for the outsourcing project spend time in the outsource
location. While analysts recommend that managers spend a month in the outsourced location
in order to fully understand the cultural nuances of the place, a shorter length of time - even a
week - can be helpful. Team building exercises are recommended during this stay.
Interview individual team members to ensure that they will be suitable for your organization’s
needs. Also, double-check that the people you interview are the team members who will
actually be doing the work.
Additionally, ask for approval for future personnel changes.
Address the issue of culture and previous outsourcing experience in the Request for Proposal
(RFP) document. The culture of the outsource company that you may be working with should
be adequately described.
Ask the outsourcing vendor to engage employees in team building and general training
activities on a regular basis. Some examples include learning about your organization’s
culture and taking English classes.
Train the outsourcing provider. Provide the vendor with information about your company
culture so that the vendor will have a better understanding of your company’s values,
communication methods, and other pertinent cultural information.
Educate your employees. Provide information about the outsourcing vendor on your
company website. Also, it is important to provide information about this vendor through a
company email or newsletter.
Find a way to improve both the communication and the collaboration between the different
teams. A good way to achieve these particular goals is to have regular personal contact with
each other and to engage in team meetings on a regular basis. Allowing team members to
Agile
freely engage in giving regular feedback is another effective strategy for encouraging clear
and concise communication among all team members
Set some ground rules. For instance, it is important to clarify at the beginning which party is
responsible for the quality of the end product.
Make sure that you clearly define what success is – and be sure to celebrate successful
benchmarks so that enthusiasm will be built within the outsourced vendor.
Determine who makes periodic reports and how often these reports are made. After all, these
types of reports allow you to measure the progress of your project.
Conclusion
Understanding cultural differences within a software development context is extremely
important to organizations from a productivity and monetary point of view because people
matter more in our industry than elsewhere. To enjoy the great benefits outsourcing can give,
you should take appropriate precautions to ensure that both your company and the outsourced
partner overcome cultural barriers that may arise. If cultural differences are handled in an
effective manner, the advantages gained from working with an outsourcing partner will be
extremely beneficial to your organization – and to your bottom line in turn.
It’s up to you to decide which direction to go with outsourcing and which way to minimize such
unobvious but important factors in globalization.
About the Authors

Serhiy Kharytonov is the EVP, Consulting Services at SoftServe (http://www.softserveinc.com),
a leading global provider of proven high quality software development, testing and consulting
services. Mr. Kharytonov has worked in the company since 2000, and was previously in the
positions of Vice President of Technology and Vice President of R&D Services. He holds a Master’s
Degree in Computer Science from Lviv Polytechnic National University, Lviv, Ukraine, and is
currently finishing his PhD.
Yuliya Sorokhan is the BA Methodologist, BAO, at SoftServe (http://www.softserveinc.com), a

leading global provider of proven high quality software development, testing and consulting
services. Ms. Sorokhan has worked in the company since 2004, and was previously in the
positions of Quality Assurance Manager and Partnership Program Manager. She holds Master’s
Degree in Applied Linguistics from Lviv Polytechnic National University, Ukraine, and is currently
finishing her PhD.
PROJECT MANAGEMENT
Project Management
Five Pillars of Practical Project Management

There are only five pillars of practices that make a project manager successful. Is it hard to believe?
Read on to find out.
Really? With such a preponderance of project

management literature it is hard to believe there
are only five pillars of practices that a project
manager has to engage in to maximize their
potential for success. OK. What are they? I’ve got
to see them.
The five steps include:
1. Project Planning
2. Project Baseline
3. Reporting
4. Change Control
5. Project Closure
That’s it. If project managers can do these five things, and the little things behind them, they will
see great gains in project management performance and greatly enhance their ability to succeed.
Sounds simple enough, but sometimes the simplest things are the hardest ones to accomplish.
Project Planning
Project managers need to stop over-complicating this initial phase. In its basic form, project
planning focuses on identifying and documenting items related to a project’s scope, time, and
cost. In short, it is the basic process of documenting the understanding each party holds related
to the project.
Nothing else should be allowed to creep into this phase. The worst thing that happens at this
stage is when project managers take a project plan and start adding little things to it. The project
plan must be matched with the project’s size and complexity and tailored accordingly. It is not a
one size fits all approach.
Project Baseline
The project baseline captures the project’s predicted scope, time, and costs at the very beginning
stages, or anytime thereafter if someone chooses to change them. In other words, it’s a snap of
Five Pillars of Practical Project Management
the chalk line. Project teams must treat the baseline as sacred, and only modify it through the
change control process as described below.
This is possibly one of the hardest things to get through to project managers, and once again
culture is the culprit. If a company’s culture is one where people tear one another down when
mistakes are made, then people are always going to hedge their bets. Nobody thinks what
they’ve got is going to be good enough, and therefore they overestimate what can realistically
be done. Project managers must become good at knowing when good enough is, well, good
enough, and have the discipline to tow that line.
Reporting
Reports should be based on variances from the baseline in terms of time, cost, and scope, and
they need to be metric-based to ensure people are collecting information on a regular basis. If
metric-based reporting doesn’t occur, then managers won’t ever get the data they need because
no driver or reason exists for collecting it.
Good reporting ensures all people are collecting important information on a regular basis, and
keeps all project managers out of the fantasy world they so often like to inhabit. It keeps them
anchored in reality. Most project managers don’t like to report on progress, and yet somehow
they continue to believe (i.e., hope) they will magically improve anyway. Reporting provides a
snapshot of where project managers and their projects really are at any given time, not where
people wish them to be.
Change Control
The change control process is meant to protect sacred project baselines while helping to manage
key expectations among project stakeholders. The very word ‘control’ implies that somehow the
process is intended to stop something from happening. But while change control does need to
be a strict process that treats the project baseline as holy, it does not need to be inflexible. This is
an important distinction that eludes many practitioners, much to the detriment of project results.
The main goal of the change control process should be to get and keep everyone on the same
page, foster discussion, and then realign expectations when necessary. Rather than emphasizing
control per se, project teams should be placing more emphasis on collaboration. In other words,
everyone needs to view projects with all three major criteria in mind – cost, scope, and time – as
this is what leads to project success. If, for example, a change in time is requested, there will likely
need to be some give and take in the other two areas to accommodate such a request. When
project managers are able to see the big picture, they are much more willing to compromise on
certain issues if it means realizing a greater overall result.
Project Management
Simply put, change should not be feared. However, stakeholders must understand that they
can’t get something for nothing. Instead of prohibiting any adjustments, the change control
process should foster the free exchange of ideas, negotiation, collaboration, and a realignment
of expectations. It should not be a cold gaiting process or be characterized by one transaction.
Rather, it requires multiple iterations, and often times relationships need to be nurtured. This
approach serves to remove ambiguity in expectations, and is the only process by which the
hallowed baseline should be changed.
Project Closure
When one project finishes there is always one or more needing to start-up, often already behind
schedule. Project closure is often skipped because of this to the detriment of everyone involved.
Without closure between projects work becomes this monotonous flow of never ending intensity.
Closure is important intellectually and emotionally. There is no hiding when a stakeholder is
asked to sign off on the projects. They either do it or continue the project. It forces finality.
Lessons learned must then be collected to broaden the project team’s and the organization’s
experiential base.
Finally, a get together to enjoy each other’s company, replay the good memories, laugh at the not
so fun ones builds emotional bonds between project members and encourages us to move on
and embrace future challenges.
Don’t underestimate the amount of effort it takes to master these five areas. They contain the
bulk of project challenges and forgo the nice to know stuff. That’s why the five pillars are so
important. They keep project management practical and reap efficient success as a result.
About the Author

Ben Snyder is the CEO of Systemation, (http://www.systemation.com), a project management,
business analysis, and agile development training and consulting company that has been training
professionals since 1959. Systemation is a results-driven training and consulting company that
maximizes the project-related performance of individuals and organizations. Known for instilling
highly practical, immediately usable processes and techniques, Systemation has proven to be
an innovative agent of business transformation for many government entities and Fortune
2000 companies, including Verizon Wireless, Barclays Bank, Mattel, The Travelers Companies,
Bridgestone, Amgen, Wellpoint and Whirlpool.
Value Triple Constraint: How to Evaluate Project Value Delivered
Value Triple Constraint: How to Evaluate Project

Value Delivered
How to use VTC (Value Triple Constraint) to quantify project value delivered while understanding
actual benefits and detailed ROI.
How do we measure project success? Do

we measure budget and schedule or do
we measure net value delivered to the
organization? Today, we tend to measure the
former. But it is the latter, delivered value, which
is the truer measure. This is the way projects will
be evaluated in the future. The current Triple
Constraint focuses on the delivery portion of a
project, rather than its business value. It focuses
on a single project, and is primarily based on a
cost view.
The Value Triple Constraint is an evolution of the Triple Constraint. It is a framework for measuring
the on-going value delivered through projects and for bringing to light the “value left behind”. It
is pictured below
Exhibit 1 - Value Triple Constraint
The Value Triple Constraint states:
Value delivered is a function of the Scope of the business opportunity and of our Capability to
identify, decide and deliver to the opportunity.
Project Management
From a business perspective, a project is aimed at taking an organization from one level of
measured performance to a higher level of measured performance. To determine if we have
achieved that objective we need good methods of measurement.
The Value Triple Constraint: Tracking Four Distinct Phases

The Value Triple Constraint (VTC) tracks an opportunity through each of four distinct phases as
follows, from last to first:
Realization Phase. This is where we implement the output product or service and begin
to harvest the results. Naturally, we want to deliver a positive value. In reality, this may be
considered mostly outside the project, since it occurs after the project is complete.
Delivery Phase. This is our current focus of attention. It consumes most of the effort, attention
and costs of the project. It is the phase where we apply the classical triple constraint. However,
the conditions for business success are largely set before this phase, outside the actual
project. Also, while the project is being delivered, the eventual benefits are being delayed and
so speed of delivery is important.
Decision Phase. This is the phase where we select among the many to decide which projects
will go forward and when. Although this phase doesn’t consume significant costs or effort, it
does often consume significant calendar time. It focuses on cost-benefit, not value delivered.
Identification Phase. This is not a phase with which many organizations are even familiar.
There is a point at which we recognize that there is an opportunity. However, that opportunity
may have existed for many months or many years. Just because we didn’t see it until now,
doesn’t mean it didn’t exist.
We tend to focus on the delivery phase. That’s where our budget lives. The decision and
identification phases contain very little budget costs. But they represent significant opportunity
costs. However, opportunity costs don’t show up on any P& L statements. There are no statements
that present us with value that did not show up. The Value Triple ConstraintTM measures both
value delivered, and value not delivered that could have been delivered. This is largely ignored,
yet represents a significant opportunity. To understand how the VTC approaches measurement,
we need to understand the major value components in the VTC and how they are related.
Project Value - Measuring the Outcome at the Project Level

The four major components that affect long term value delivery are:
Realized Value
Project Cost
Decision Opportunity Cost
Identification Opportunity Cost
Let us explore each of these in turn.
Realized Value. This is the actual benefit experienced after implementaion. The realized value
is delivered, over time, across organizational boundaries. Because of this and other reasons, it
is often not tracked for any meaningful period of time. And yet, it is the single most important
measure that can tell us how well we are doing overall, across all projects. Why is it important to
measure the value delivered across the entire benefit projection period? Business processes have
a way of deteriorating. So we need to know, over the entire benefit projection period, what the
value delivered was. It is not unlikely that organizations have a tendency to select a “sampling
period” that is favorable rather than representative.
Project Cost. This is the familiar budget portion of any project. Under the Value Triple
ConstraintTM, it is divided into two separate components:
1. Delivery Cost. This is the usual cost component which is reflected in the budget. This
represents money actually spent, whether capital or expense.
2. Schedule Opportunity Cost. Under the Triple Constraint we track the schedule in terms of
time. In the VTC, we track schedule in terms of its benefit equivalent. This is both new and
different.
To convert schedule time into schedule cost, we need a formula. It is calculated as:
Schedule Opportunity Cost = Monthly Net Benefit x Schedule Months
For example, a project with a projected monthly net benefit of $50,000 and expected schedule
of 10 months, would have a Schedule Opportunity Cost of $500,000 ($50k x 10 months). The
Schedule Opportunity Cost provides a better mechanism for choosing among alternative
schedule options, because it reflects the time cost of delivery - time is money.
Decision Opportunity Cost. While an organization waits to decide, no benefits can be delivered.
And so, there is a real cost to the time it takes to make a decision. The quicker we decide, the
quicker we begin to realize benefits.
Identification Opportunity Cost. We may recognize that we have an opportunity today. However,
an opportunity begins when the conditions that gave rise to it, came to be. So there is virtually
always a gap between the time an opportunity arises and when someone in the organization
acknowledges it. That gap has an opportunity cost
Identification and Decision Opportunity Costs reflect our capability with respect to those two
functions. In many organizations a focus on those two would result in the delivery of much more
value to the organization than would a focus on project delivery skills, which might already be
quite high.
If project managers wish to be more successful, then the projects need to be more successful
Project Management
from a business perspective. They need to think outside the project because that’s where success
begins. A project that will, in the end, deliver very little Realized Benefit is not going to be a
business success. Such a project is born handicapped.
Some Uses of Value Triple Constraint

The VTC has these major uses:
1. Quantify the business value of a project

2. Select from alternative schedules.
3. Look for opportunities to deliver more value through speed along the entire opportunity
chain.
To reduce risk on a single project, we should continuously update the Value Profile, not just the
costs. This would include:
1. Projected Realized Value

2. Projected Delivery Cost
3. Projected Schedule Opportunity Cost
By tracking and projecting all three, we could detect some important things that we don’t
currently manage. For example, if the projected Realized Value begins to decline and the Delivery
Cost begins to increase, we know there is the risk that the project will be cancelled. And perhaps
it should. Also, if the Realized Value after completion shows a tendency to be less than predicted
then perhaps projects are being oversold.
On the other hand, when the projected Realized Value increases, then our projected Schedule
Opportunity Cost will also increase. This should tell us to revisit the schedule because time has
become more valuable.
What about scope management? When an increase in scope results in an increase in the
schedule, we should take the additional Schedule Opportunity Cost into consideration. For
example, an increase in scope may result in an increase in the Realized Value of $100,000, an
increase in cost of only $30,000, and an additional two months of schedule.
Without looking at the schedule impact this seems like a simple decision. But it the benefit
was $50,000 per month, then we would incur an additional $100,000 (2 months) of Schedule
Opportunity Cost in addition to the $30,000 Delivery Cost. This changes the equation. The
organization would be paying $130,000 of value to gain only $100,000. Suddenly it doesn’t make
sense any more.
Another example is a change request which is in budget but does not increase the projected
realized value. This should be declined because the net Value would decrease and should be
declined. Today, the tendency is to accept a change which is in budget, even if it adds no value.
Projects exist to capitalize on opportunities. Therefore, we need to measure lost opportunity just
as much as measuring adherence to an estimate, which may not even be correct.
Enterprise Value - Measuring the Outcome at the Enterprise Level

How do we determine what the optimal sequence is for projects? Look at the following example.
We have two projects requiring the same resources. So which do we do first
Exhibit 2 - Comparing ROIs
From an ROI perspective, Project A appears more attractive and so we might be tempted to do it
first. But, by including the schedule cost, we can compare the two alternatives.
The total Realized Value and the total Delivery Cost are the same regardless of order. However, the
total Schedule Cost is different for each alternative.
If we do A first, then the Schedule Costs will be:
Schedule cost for A is 12 months at $50,000 per month or $600,000

Schedule cost for B is 12 months waiting for A to finish, plus 12 months to complete B for a
total of 24 months. Each month is worth $75,000 (benefit from B) for a total of $1.8 million.
Total Schedule Cost for this alternative is $600,000 + $1.8million = $2.4 million
If we do B first, then the Schedule Costs will be:
Schedule cost for B is 12 months at $75,000 per month or $900,000

Schedule cost for A is 12 months waiting for B to finish, plus 12 months to complete A for a
total of 24 months. Each month is worth $50,000 (benefit from A) for a total of $1.2 million.
Project Management
Total Schedule Cost for this alternative is $900,000 + $1.2 million = $2.1 million
Clearly option B is has the least opportunity cost and, therefore, the highest value, which may not
be the intuitive choice.
Program, Project, Portfolio and PMO

How do projects, programs and portfolios relate? First, we begin with a quantifiable business
opportunity, and designate a program for it. Then, as we determine all the projects required
to deliver to the business opportunity, they become part of the program. Beginning at the
opportunity/program level provides us with a way to pull necessary projects into the measurable
program, rather than trying to group projects after the fact. The VTC can be used to determine
the best way to organize and schedule projects within the program and also helps determine
sequencing for programs. Once we apply the VTC to a program, we can determine what criteria
we wish to use to develop portfolios.
Exhibit 3 - How Projects. Programs and Portfolios Relate
Summary
The Value Triple Constraint moves the focus from the project manager to project management as
a whole. It requires the business to take responsibility for establishing and confirming the benefit
and focuses attention on the opportunities of identification and decision in addition to delivery.
It requires the quantification and validation of actual project benefits. This will discourage any
practice of overstating benefits to get approval and then abandoning that metric. The proposed
VTC model gives us a better way to evaluate project success. It also allows us to focus our
attention on where the true opportunities lie. If most of the value lost is in the identification and
selection, then there may be more opportunity in improving how we identify opportunities and
how quickly we make decisions rather than improving our delivery capability.
About the Author

Angelo Baratta, PMP, CMC is dedicated to significantly raising organizational capabilities. His
ePPMTM framework goes beyond best practices. It is a scientifically engineered system for raising
the effectiveness of project, process and requirements management - key competences for all
organizations.
Web: http://www.PerformanceInnovation.com
Email: ABaratta@PerformanceInnovation.com
Project Management
Why Project Scheduling Must Not Become an

Extinct Science
New demand for project scheduling expertise is driving change in the market place. Learn the key
project scheduling strategies for 2010.
After spending the past decade or more

dedicated to project management, I noticed
during the economic downturn last year a
very surprising trend: despite the significant
reduction in the number of major Capex projects
being sanctioned and funded, the need for third
party assistance with schedule analysis and risk
assessments actually increased dramatically.
After digging into this a little more deeply, I
came to the following conclusion: savvy project
schedulers are at risk of becoming a dying breed
and as project management specialists, we need
to do everything we can to reverse this trend.
The software tools available to planners, schedulers and estimators are more powerful today than
ever with the likes of collaborative, web-based, multi-user capabilities and yet as a profession we
still struggle to bring projects in successfully under the triple constraint of cost, time and scope.
Savvy project schedulers are at risk of becoming a dying breed and as project management
specialists, we need to do everything we can to reverse this trend.
A previous survey carried out by Bull Computer systems showed that 57% of projects failed due
to inadequate communication and 39% failed due to poor project scheduling. Similarly, well
publicized reports such as the Standish Chaos Report all list pessimistic statistics and multiple
causes of project failure.
From a project management perspective, my theory is perhaps somewhat more straightforward. I

stand behind the belief that there are only two root causes of project failure:
1. The project plan set out by the PM team was unrealistic in the first place.
2. Project execution wasn’t able to perform to the expectations of the project plan.
While, perhaps these causes initially sound very obvious, in reality they are hard to dispute. It’s
really all about successfully “planning the work” and “working the plan”...
Why Project Scheduling Must Not Become an Extinct Science
Let’s now consider how to overcome this first cause of failure.
The Keys to Successful Planning

Critical Path Method (CPM) scheduling is the de-facto standard for project scheduling. Estimating
durations, sequencing work and assigning resources are all common steps in creating a CPM
schedule. Yet all too often, the end result is a plan that is either unachievable or unrealistic.
It’s All About Top Down Planning

One of the major pitfalls when creating a project plan is to jump straight into the development
of the planned work (activities) rather than adopting a more formal, top down approach which
tends to be more successful, of defining the project objectives, elaborating scope definition,
expanding out the deliverables and Work Breakdown Structure (WBS) and then, and only then,
start to detail out the work (activities and resources) required to satisfy these deliverables.
A well-developed schedule should be able to be rolled up through a WBS to show the entire
scope of the project with the underlying work required encapsulated as activities. All too often,
project plans omit this formal structure which then leads to inevitable project scheduling
challenges.
Figure A: Deliverable-based Planning
Definitely Maybe...
Project scheduling has historically been a deterministic science. That is to say, activities have had
definitive durations assigned, single-point cost estimates and so-forth. With the advent of risk
analysis, such an approach is being replaced with non-deterministic estimates that combined
with risk analysis techniques give not only forecasted completion dates, but more importantly
Project Management
give confidence levels as to how realistic these completion dates are.
The term “Risk Analysis” tends to portray impacts from risk events such as weather, mechanical
failure etc. In reality though, most risk regarding project success is actually driven by poorly
defined scope. In my experience, I have discovered that 75% of the risk exposure within projects
actually comes from scope uncertainty and not discrete risk events captured in a risk register.
While this is a huge percentage, it is actually good news from a planning perspective as scope
definition is typically easier to handle and reduce than external risk events. Again, further proof
that a sound project plan needs to be closely tied to a well defined scope definition.
Not only does this certainty-based project scheduling help with pinpointing problematic areas
within a project, it also gives the project execution team a range of dates to target rather than
being setup for failure against a single date.
Seeing the Wood for the Trees

Sitting in a recent project review meeting, I experienced a project manager requesting a copy of
the project plan. When the lead project scheduler provided their 5,000+ activity Gantt chart in a
PDF file, the response from the PM was “yes, that’s great but where’s the one the team as a whole
can understand.” This is indicative of how schedule’s can be overwhelming to project teams.
Project schedules are designed to capture as much information as possible but in doing so they
quickly become hugely complex and unwieldy. Anyone that has tried to determine the paths
between say two milestones in a schedule will know first-hand how difficult this can be. To
compliment Gantt charts, what is needed is a means of summarizing or grouping key activities,
yet still retaining the underlying sequence of work.
Similarly, when analyzing a project looking at cost, schedule, risk and performance, it is much
more valuable to be able to do so by selecting groups of activities. These groups may be
disciplines, locations and type of work as well as different phases within the project. Having an
insight into the scope and associated performance of a project by time phase and by discipline
is much more valuable than looking at these metrics averaged out at the project level. This
matrix-type of project analysis is an area that is gaining significant traction and one that is hugely
valuable to a project team.
Figure B: Project Visualisation Through Ribbons and Phases
Why Project Scheduling Must Not Become an Extinct Science
Analysis Paralysis!
The ultimate objective of developing a project plan is to have a target against which to track
performance. Over the years, numerous types of analysis techniques have been developed to try
and determine project performance. However, I still go back to the two fundamental causes of
project failure. Wouldn’t it be more useful if we could correlate the fact that poor performance in
a specific area of a project was actually due to unrealistic planning? In other words, pinpoint the
planning weakness so that it can actually be addressed!
Project metric analysis goes well beyond just applying formulas or calculations such as “Total Cost
Overrun” or “Number of Activities with Missing Logic.” Instead, metric analysis combines formulas
with thresholds or trip-wires that give meaning and context to the results from the formulas.
Does knowing we have “fifteen open ended activities” or “five missed deadlines” really tell us
anything meaningful? Wouldn’t it be more useful to know the impact of the open ended activities
and the cost and schedule implications of the missed deadlines? What if all five missed deadlines
were only a day late on a three year project? In this example, it’s arguable as to whether such
exceptions should even be reported.
The likes of the Defense Contract Management Agency (DCMA) are now publishing such metrics
and trip-wires as a means of standardizing schedule quality checks as well as setting standards for
contractors to aim for. Such initiatives are a welcome breath of fresh air to scheduling and I expect
to see similar initiatives across multiple industries in the near future.
Figure C: Example of DCMA 14 Point Assessment Analysis
But the Goalposts Keep Moving...

Maintaining an up-to-date schedule is a difficult enough task during the planning phase of a
project but it becomes infinitely more involved during execution.
Project Management
During the planning phase of a project, scope invariably tends to be somewhat fluid which in
turns results in the required work also being somewhat of moving target. During execution,
even in an ideal world of locked down scope, keeping track of actual performance and reflecting
remaining work in a schedule can be very challenging and often muddies the true picture as to
how well a project is performing.
To overcome this reporting challenge, project trending can give a much more useful indication
of performance than simply looking at a single snapshot in time. Knowing a project is ten weeks
behind schedule tells us absolutely nothing regarding whether our performance is improving
enough to claw the delay back or even worse, if our performance is deteriorating, how much
further delay can we expect? With the proper use of a comprehensive metrics analysis tool, this
can easily be overcome.
Many projects have done a good job of tracking performance trending during execution, but few
actually track trending during the planning phase. Relating back to the first root cause of project
failure, project planning is often an iterative process and as such, there is massive value in also
running trending analysis against the quality of a plan during the planning phase.
Tying “Planning the Work” to Successfully “Working the Plan”

The second identified cause of project failure was the inability to execute according to a given
plan. I believe the solution for the second identified cause of project failure is actually more tied
to solving the first identified cause! If indeed we can successfully plan and forecast the work
that is required for project completion and this plan then accurately accounts for uncertainties,
complexities and risks that may occur during project execution, project failure will then be a
thing of the past.
Such a scenario is of course the perfect case, but by adopting the practices described above, we
are aligning ourselves more for project success than accepting project failure.
About the Author

Dr. Dan Patterson is the founder of Acumen and is recognized as a thought leader and visionary
within the project management industry. Dan was responsible for developing a now widely
accepted integrated qualitative/quantitative approach to risk analysis. His depth of knowledge
in this area includes integrated cost/schedule optimization throughout the project lifecycle.
Extending his passion for project performance tracking across multiple industries including A&D,
government, energy and EPC, Dan also has vast experience in the area of Risk Assessment and
Project Performance Management. Dan is also now very excited to be focusing on Acumen Fuse™,
the most advanced & comprehensive project analytics tool available for MS Project, Primavera,
Deltek, MS Excel and more...
More information can be found at www.projectacumen.com
Was Deming Right About Quality Management and Project Outcomes?
Was Deming Right About Quality Management

and Project Outcomes?
14 points for better project outcomes and consistent quality management
Quality is misunderstood by many who think

of it only as it relates to the final deliverable,
but a quality product is itself achieved only
through quality processes focused on efficiency,
innovation, and continual improvement, and
these require a quality management culture not
only in our projects but within our organizations.
In chapter two of his 1986 book, Out of the
Crisis, Edward Deming presented 14 principles
that he believed could make industry more
competitive by increasing quality.
Organizational improvements can begin with anyone. While it’s true that our professional domain
as project managers is bounded by the project life cycle, our influence is often much greater
than that, and quality management is one of those areas where skilled project managers are
best suited to be instrumental change agents -first in the culture of their projects, and second, in
the culture of their departments and organizations. As project managers, if we follow Deming’s
principles, we can create project environments where quality thrives, not only benefiting
our customers and projects but perhaps serving as a tipping point for effecting a quality
management change within our organizations.
1. Create constancy of purpose towards improvement

Deming is telling management to stop reacting and plan better for the long-term.
For project managers: What was has been traditionally thought of as long-term planning is no
longer achievable. Business changes too rapidly, and detailed, up-front plans take too long to
produce and are always outdated by the time they’re committed to paper.
Yet projects must have a plan that establishes activities, milestones, and priorities, so what
we should strive for in our projects is thorough planning based on iterative, rolling-wave, or
Agile approaches. Thorough planning uses detailed planning for the short-term with a longer-
term view emphasizing constant reviews, re-planning, and risk management, especially for
opportunities that can be exploited. This results in a project plan that can adapt quickly to abrupt
business and deliverable changes without throwing the project into chaos.
Project Management
2. Adopt the new philosophy

Deming is telling management to stop being hypocritical, awaken itself to the challenge, and
become leaders.
For project managers: People will always see through anyone who says one thing but whose
actions are entirely different. Lasting, energizing change starts first with us, and only then will it
spread outward and excite others into action.
As managers, our core values can’t just be expressed through our words, but they must be
evident in all our actions with our teams and coworkers. It takes time, but as our message and
attitude spread to an ever-broadening base of people, a domino effect takes place and the
members themselves become believers and evangelists in quality management themselves.
3. Cease dependency on inspection

Deming is reminding management that the need for inspection will decrease if quality problems
are prevented in the first place.
For project managers: We all know that prevention is better than inspection, so our project
management and execution processes need continual improvement methods built into them to
reduce quality problems.
But inspection goes beyond its purely quality connotations. Are we propagating a management
style based on inspection? If our team has a tendency to run everything first past us for approval
then we may be, and that isn’t good for us, the team, or the project.
Our responsibility as a project manager isn’t to be the funnel through which everyone seeks
approval. If that’s what is happening then the project will stagnate and become inflexible.
Instead, let’s make sure we create a project culture where the team has the skills, information, and
experience it needs to make every-day, rapid decisions on its own.
4. End the practice of awarding business on the basis of price tags

Deming’s purpose behind this point was to eliminate variations in the manufacturing process by
having too many suppliers of component goods.
For project managers: Price alone should rarely be the determining factor because most
procurement needs go beyond simple commodities. When a project is likely to involve frequent
changes, we need vendors who can adapt or offer their own new ideas for responding to those
changes, and that isn’t likely to happen when cut-rate suppliers are chosen.
This principle also holds true in our role as the vendor for internal or external customers. We
are not just collectors of requirements — we need to be engaged with the customer and
stakeholders, understanding their business objectives in order for us to provide the deliverable
that best meets their changing needs.
5. Improve constantly and forever

Deming is reminding industry leaders that they have to constantly strive to reduce variation,
which leads to quality problems.
For project managers: Continuous improvement is a core philosophy of the PMBOK, but it isn’t
like a switch that gets turned on or off. It’s a mindset that is nurtured by the right environment.
Members of the team need skills, information, and knowledge beyond their core subjects of
expertise, and we should encourage experimentation and reward mistakes made in the search for
innovation, which means we need to eliminate blame and ingrain the lessons-learned process in
every part of the project.
Large-scale improvements and innovative approaches often come from “amateurs” and not
specialists because amateurs are driven by their interest in the subject and less wedded to
preconceived notions and ideas. Chris Anderson, author of The Long Tail, says, “I’ll take a
passionate amateur over a bored professional any day.”
6. Institute training on the job

On-the-job training increases efficiency and results in job outputs with fewer errors.
For project managers: Continuous improvement extends beyond just processes. It applies to
the hard and soft skills, experiences, and knowledge of the entire project team. Professional
development, coaching, and mentoring should be encouraged, acknowledged, and rewarded.
Training doesn’t have to be expensive, and it doesn’t have to be formalized. Some of the best
training experiences involve group-led efforts that also serve as team building exercises, such as
webinars, vendor demonstrations, and specific discussions on best practices.
7. Institute leadership
Deming wants management to be leaders not merely supervisors.
For project managers: The problem on most projects is not a lack of management but a lack of
leadership. Leadership is more about people skills than about project management skills. Few
projects have sponsors that view themselves as the leader on the project, and if the leadership
charge is not picked up by the project manager then the project is not likely to be successful. A
leader translates the project’s vision into actions that excite, inspire, and motivate the project
team, and he or she is able to instill a perception that the project isn’t just creating a deliverable;
it’s accomplishing something phenomenal for the customer.
Project Management
8. Drive out fear

Deming tells us that management by fear or punishment is detrimental because it inhibits
questions and ideas from the workforce.
For project managers: Fear stifles two cornerstones of quality — innovation and continual
improvement. A fearful team isn’t going to generate new ideas and it’s going to hide its mistakes,
leading to a poor lessons learned process. Deming’s point goes beyond what most of us associate
with fear. Fear is also that little voice all of us hear that suppresses us from speaking up or sharing
ideas -fear of failing, fear of sounding silly, fear of making a mistake, fear of missing a deadline,
fear of stepping on another’s toes, and so on. Yet these fears are just as detrimental to quality as
fear of punishment.
It’s a lack of trust between team members and in the project’s leadership that drives these fears.
If we improve trust, team members will be more willing to share their ideas and question existing
processes.
9. Break down barriers between staff areas

Deming wants everyone to realize that each person is a customer of someone and that
everybody is a supplier to somebody.
For project managers: Silos and a rigid hierarchy are dangerous not only to the project but to
the organization. Innovation and continual improvement come about by somebody seeing a
connection that is not inherently obvious, and connections can’t be discovered when one is stuck
behind artificial barriers.
We can help break those barriers by exposing people to diverse situations outside their normal
environment and comfort zones. Though there is a short-term productivity loss when people
work outside their specialty, there is a longer-term gain for the project and organization. This
strategy helps build a larger pool of “generalists” in many subjects, and new experiences are a
powerful motivator for many people. This approach also improves opportunities for innovative
approaches and is a risk management strategy should key personnel leave the project.
10. Eliminate slogans, exhortations, and targets for the work force
Slogans imply the problem is with the employees, but the real problem is with the process.
For project managers: The first point we have to accept is that we are responsible for problems
within the project, whatever those issues might be. It isn’t the team’s fault, the customer’s fault, or
the organization’s fault -it’s our fault.
The root causes of most project problems are deficiencies in communication, scope,
requirements, activity definitions, project planning and re-planning, risk management, and
stakeholder involvement. All of these are within our professional domain even if we aren’t the
ones personally performing them. It’s our responsibility to make sure the project processes are
performed effectively to a level appropriate for the project.
11. Eliminate management by objectives

Setting production targets only encourages people to meet those targets through whatever
means necessary, which causes poor quality.
For project managers: On the surface this principle probably sounds like heresy to most of
us -how can a project be managed if targets aren’t set? Well, it can’t, but that wasn’t Deming’s
point. He’s talking about short-sighted versus thorough planning. Setting targets in response to
a problem without first understanding and addressing the root causes in the processes will only
lead to more quality problems.
Milestones are the predominant targets for projects, and they need to be challenging to motivate
the team, but they have to be achievable and flexible. Yet flexibility is one of the most common
scheduling failures a project manager makes, especially on projects that are very iterative and
involve rolling wave planning.
As these projects progress, milestones have to be continually reassessed, and this often means
that the original dates get pushed. Too many of us perceive these readjustments as “missing our
target” because we’re too married to dates that were only best-guesses or top-down estimates
set early in project planning. We also should be careful to present milestone dates to stakeholders
as estimates and help them understand the iterative nature of these kinds of projects — as the
project is better understood and the work needed becomes clearer, milestone dates may change.
12. Remove barriers to pride of workmanship

Deming tells us that nobody feels good about producing shoddy work. When management
creates an environment that fosters poor quality, employees are frustrated.
For project managers: Recognizing the team and individuals for their contributions and
achievements helps instill pride of workmanship. Everyone on the project team should feel that
his or her work is recognized and valuable to the project’s success. Sincere appreciation is one
of the easiest and cheapest yet most effective motivating agents we can use. Even “failures” and
mistakes are achievements as long as there were valuable lessons learned.
13. Institute education and self-improvement

Deming wants everyone, managers and the workforce, to pursue training, education, and self-
improvement.
Project Management
For project managers: Ongoing professional development is expected of certified project

managers, but we should also expect and encourage it among our team and coworkers. Nearly
every profession has its own certification and continuing education requirements, and our team
members will appreciate it if we have a general understanding of their profession’s requirements,
recognize them for certification efforts, and help them with opportunities for meeting those
requirements.
14. The transformation is everyone’s job

Deming says that everyone is involved in the fixing the processes.
For project managers: This one is easy if we’ve done everything else right because all the other
principles will result in quality management culture where everyone is involved in continual
improvement and innovation. Having experienced first-hand a quality management experience,
the people on our team will in turn spread those ideas to other project teams.
Copyright 2009 J. Alex Sherrer, Project Management Road Trip
J. Alex Sherrer is the author of the Project Management Road Trip for the Project Management
Professional (PMBOK, 4th Ed.).
Build Your High-Performance Virtual Team: 7 Key Steps
Build Your High-Performance Virtual Team: 7 Key

Steps
How to accelerate virtual team formation and cultivate top-notch teams
As the leader for a new global project team, you

need to get everyone on board right from the
start with energy, enthusiasm and commitment
to work as a team. As a seasoned project
manager, you may be adept at shepherding
project teams through the usual phases of
forming, forming storming and performing.
But this time it’s different, since most of the
members will work from a distance for the
duration of this two-year project.
Joining me in writing this article is Kathy

Connolly, founder of The Office Outdoors, a team development consulting firm. We show how
some of the essential activities for building any high-performing team can be applied to project
teams who must work virtually to get the job done.
Choose the right people

When you have the ability to influence who participates (and this is not always possible),
look for people with diverse perspectives with the right combination of skills, knowledge and
experience. To operate successfully as a member of a virtual team, however, people need certain
competencies that others may not. Examples: tolerance for ambiguity; sensitivity to cultural
differences; willingness to work independently; ability and openness to communicate using a
variety of methods, both asynchronously and synchronously; and keen listening skills.
Make shared goals explicit

While crucial for any team, this is more important and far more challenging for a virtual team.
More important, because virtual teams have few opportunities to correct misunderstandings,
fine-tune agreements, or debate differences. Without clear shared goals, virtual team members
can more easily inadvertently veer off in different directions and become derailed quickly. More
challenging, because few virtual teams allocate the kind of time necessary for the kind of in-
depth conversations needed to hammer out explicit goals that all understand and agree to. Set
aside a series of virtual meetings right up front to make the goals explicit, and make sure that
everyone has an opportunity to reflect and revise.
Project Management
Develop ground rules tuned to a virtual team

For example, agree on who needs to attend which meetings and how frequently. Be specific
about the extent to which multitasking is acceptable on team calls. Discuss the consequences of
failure to do important prework. Agree how conflicts will be resolved among members. Establish
an agreed-upon protocol for handling distracting, disrespectful or disruptive behavior. Agree who
needs to be on the “to” list for certain topics and who can be simply cc’d. Establish conventions for
sharing, editing and posting vital documentation, including editing and approval rights.
Facilitate connections
Any time a new team is forming, people need time to cultivate trust to work well together. Team
members who work virtually, however, often have few chances to really get to know each other
beyond their respective deliverables and due dates. You can facilitate the getting-to-know-you
process many ways. For example, invite people to complete a bio that helps to draw out the real
person behind the voice. Ask for a picture and information about special skills or qualities, where
they’re from and where they live, languages spoken, values they live by, professional credentials,
preferred communications method, etc. Post bios on a shared website and encourage people
to make connections. Keep in mind that face time is the best way to build a new team. Leverage
corporate events, sales meetings and conferences to bring people together without making too
big a dent in your budget.
Model best practices

For example, show up to con calls on time, fully prepared to participate in a productive
conversation. Be respectful of others’ ideas by practicing generous listening. Avoid the
temptation to multitask, even if your inbox is on serious overload. Use IM judiciously, which may
mean inviting a reluctant participant to contribute or asking someone for additional data. Do not
use IM to have a side chat that will distract you and others from the conversation at hand. End
meetings on time, and make sure that you’ve kept the team focused and on track in achieving
your intended outcomes.
Make work fun

Give people permission to make everyday interactions fun. All work with no play can suck the
energy and spirit out of people. Playfulness and a sense of humor help people relax, bond and
de-stress. Example: Start a virtual meeting off with some type of sharing that’s not directly
related to the task at hand. For example, you can start by revealing your greatest frustration for
the week, keeping a light tone. Or talk about where you’d most like to be right now, if not in this
terrific meeting. Send a humorous sound or video file that everyone can enjoy at the start of the
meeting. Make sure to strike the right balance between having a social conversation and allowing
people to focus quickly on the work at hand.
Build Your High-Performance Virtual Team: 7 Key Steps
Celebrate achievements, milestones and successes

Most projects go through certain phases when the work is stressful and the potential for burn-
out or withdrawal is high. Show appreciation for contributions, achievements and sacrifices
by making 1:1 contact with each team member. Send cards, either the paper or virtual kind, or
personal emails. Or try picking up the phone to say thanks and check in. Get sponsors and other
managers involved in showing appreciation, including public acknowledgement via emails, in
meetings and in company publications. Plan virtual team celebrations by sending gift certificates
for coffee, pizza or dinner. And perhaps the best reward of all: Give team members well-deserved
time off when special milestones are met.
Like any other team that’s starting up, a virtual team will undoubtedly move through the phases
of forming, norming, storming and performing. Your challenge is to accelerate the time it takes to
cultivate a high-performing team by applying sound project team development principles in new
ways that reflect the unique dynamics of a virtual team environment.
About the Author

Nancy Settle-Murphy is president of Guided Insights, a facilitation, consulting and training
firm in Boxborough, MA. Enabling geographically dispersed IT project teams to collaborate
more effectively is a special area of focus. Her articles have appeared in publications such as
The Meeting Professional, Mass High Tech, IT Executive Journal, PM Network, and Association
Management Magazine.
Visit her company website at www.guidedinsights.com
Project Management
Common Project Management Hurdles and the

Challenge of Change
Learn how to manage change issues and improve your project management processes
No matter how well a project is planned and

how well the requirements are defined, there
will always be requests to change something
about the project, usually the product being
delivered. There are good reasons for this;
business doesn’t stand still while your project is
going on so we expect that ongoing business
will trigger the need for changes to the system
being built to support that business. These
changes are mission critical to the project in
many cases. If the system isn’t changed to
reflect business needs as they will be when the system is implemented, your project will succeed
in building a system to support business as it was done 6 months ago! These changes are why
project managers need a good Change Management Plan and process.
Failing to properly plan the project’s work or sloppy requirements gathering will certainly lead to
requests for change and will probably overwhelm the project’s resources with change requests
to analyze and implement, no matter how solid your Change Management Plan and process are.
Failure to define a change management process that meets your project’s needs and plan process
activities will lead to: the wrong changes being implemented, budget wasted on the wrong
changes, failure to reserve sufficient time for analysis of change requests, refusing changes that
would add value to the project, exceeding the budget, and late delivery.
Project length is another source of change requests. The longer the project goes on, the more the
business changes, the more the business changes, the more the system must change to support
the business. The insulation of the development cycle from the impact of change is one objective
of iterative development methods. With iterations, fewer changes are likely to be requested.
Software development projects with long delivery time lines can expect to experience a flood of
change requests towards their end.
All changes are not created equal. Another common error in the area of changes is the tendency
to treat all changes in the same way. The administrative effort required to process a request to
change the color of a button on a website screen from red to maroon should not be the same as
a request to double the number of pages on the website. Attempts to force requested changes
through a laborious process designed to support major changes to project baselines will meet
Common Project Management Hurdles and the Challenge of Change
with resistance. There are two possible outcomes here. Either the team will prevail and will start
making the minor changes behind your back or you will prevail and stifle minor changes that
ought to be made because they add value to the product.
Yet another common mistake is to have the wrong people make decisions about changes. This
mistake is related to the failure to provide different processes for different changes, but it is
possible to provide the right process for each magnitude of change and still identify the wrong
people as decision makers. The decision makers for a change should be those people, or that
person, who has the best grasp of the pros and cons of the change. The decision maker should
also be someone who has the authority to approve any budget changes. The decision on whether
to approve the change in the colour of the web screen button should be made by someone
who is knowledgeable enough about web design to predict its affect on users. The decision on
whether to double the number of screens, and probably double the cost of the project, should
be made by someone who has the authority to double the budget. This may be a customer, a
sponsor, or an executive steering committee.
Project managers often make the mistake of assuming that because they have asked the project
team and stakeholders to read a document (e.g. their Change Management Plan) that they will
read and understand it. You should make the document available for reading by posting it to a
site where everyone you expect to read it has read access, but too often project managers will
stop there. The result is usually that changes are made without project approval, and/or the team
attempts to follow the process but fail to follow it properly creating more work for the project
manager.
Avoidance Strategies
Start your project with a good change management plan. A good change management plan
should accommodate any change likely to occur on your project. The plan should support all the
best practices described in the PMBOK, but be tailored for the size, complexity, and industry of
the project. You should define at least two processes, what I’ll call “Change Management Lite” and
“Change Management Full.” Change Management Full should be suitable for large scale changes,
up to and including those that must be decided upon by your customer, sponsor, or executive
steering committee. Change Management Lite should accommodate the smallest change. Make
sure that the administrative overhead entailed in each process is proportional to the size of the
change.
A good plan identifies the actions and tasks that must be performed to follow the process,
assigns people to those tasks, and identifies any deadlines that must be met. Allow sufficient time
in your schedule for the tasks to be performed. Since you can’t predict the number of change
requests you will receive, or how complex those requests will be, over the course of the project
phase you will need to set buffers. Set your buffer for each iteration, if you are using an iterative
development method. One way of dealing with the uncertainty surrounding number and
Project Management
complexity of change requests is to raise an alert when a buffer is approaching total depletion
(say 90%). You have two choices when you reach that point: you can shut the change process
down (OK if you are almost at the end of the project), or you can request a change to provide
more time to deal with change requests. This change will require either more resources (increase
the budget) or reducing the scope.
Identify the proper decision makers in your plan. The customer, or client, or sponsors, or executive
steering committee should be responsible for making decisions that will change the baseline.
These individuals must understand what is expected of them, when they must render decisions,
and how they will receive the information they need to make the decision. For changes that
don’t change the schedule, budget, scope, or quality baselines, identify one of the project team
as the decision maker. You should be the first in line after the executives, but you should not be
required to render decisions on issues which do not require a change in the project plans. Take
our web page button as an example. It will cost no more to create a maroon color button than
it will to create the red version and you are not in a position to know if maroon is the right color.
Delegate this decision to the web design expert. The web design expert must follow the change
management process. The change will not affect your plans but will affect the design, coding,
and testing of the website. Team members responsible for those tasks must be made aware of the
change and the appropriate documents updated.
Educate your project team and stakeholders on the change management processes in your plan.
Education for requesting a change should include where the change request form resides, how to
complete it, who to send it to, when to expect an initial response, when to expect a decision, and
how that decision will be made. They should also be educated in their support responsibilities
(i.e. answering any questions SMEs who analyze their requests may have). Education for the
team should include their responsibilities when they receive a change request for analysis, the
deadlines for those tasks, and how the analysis information is to be captured. Education should
be in the form of a ½ hour - 1 hour formal training session. Do not throw a process document
or presentation over the wall and expect your stakeholders and team members to absorb its
contents.
About the Author

Dave is a principal with three O Project Solutions, the vendors of AceIt©. Dave was also the key
architect responsible for the creation of the product. AceIt© has prepared Project Managers
from around the world to pass their PMP® exams. Dave also has over 20 years of experience
managing projects of every size and training IT resources for companies like Nortel Networks
and 724 Solutions. He recently led a $100M project to upgrade a leading bank’s ATM network
for Diebold Canada. His training achievements include a PMP® Course (PMP® Exam preparation)
conducted for CPTTM in Macau, a CMM training program for Nortel Networks, and training PMP®
candidates at the Lakeshore chapter of the PMI. Visit his website at http://www.threeo.ca for more
information.
How to be a Project Goal Scoring Champion

Project goal scoring for fast, flexible and well trained development teams.
Have you ever seen a group of children play

soccer? The ball gets kicked into a corner and
every child on the field runs after it. Then the
ball gets kicked into another corner and they all
chase it there as well. It is exhausting to watch
and the game usually lasts a long time, with no/
few goals being scored.
This metaphor can easily be extended to poorly

run projects. All of the team members wind up
‘chasing the ball’ wherever it goes rather than
spreading the field and playing as a team. Often the same result occurs as the children’s game;
a long time goes by without many goals being made. This article will ponder the comparison
between a well run project and a well run soccer team.
Soccer Match
1. Watching Children Play

A lot can be learned about running projects from watching children play soccer. It seems that
project teams are always ‘chasing down’ the most recent problem like chasing down a soccer
ball. That is, they are always running to the next place that the ball is kicked. This problem usually
involves the entire team or a large part of it to solve. This means that team members are not
working on other aspects of the project, resulting in those areas having problems later. These
new problems then require everyone working on them to solve. It seems to be a perpetual loop
that is diagrammed below.
Project Management
The result of this loop is that the team is always behind the ball chasing it wherever it gets kicked.
This is usually accompanied by lots of yelling from the sidelines by the coach (Project Manager).
The next sections will discuss approaches for scoring project goals.
2. Get In Front of the Ball

The best soccer players (and project team members) are those who have learned how to ‘run
without the ball’. These players have the ability to anticipate where the ball will go and be there
by the time it gets there. By not being behind the ball, they can focus on preparation for when
the ball gets to them and they have a better idea of what to do with it when it gets there.
As this relates to projects, having a plan and being able to anticipate where the project will
go is critical to the success of the project. If a project is always chasing down issues, then they
are being controlled by the issues and wherever it takes them. Staying in front of the issues by
scoring project goals allows them to be manageable and allows for preparation as they arise.
The plan must be realistic, however. Having team members ready at a place in the field where
the ball will not go makes them unproductive. The plan must also be flexible enough to react to
deviations in the track of the ball.
3. Teamwork
One of the biggest keys to getting in front of the ball is to trust in the other team members.
This allows the players on the team to spread out themselves across the field and focus on their
respective roles. The offensive players in the front need to trust that the players behind them will
get them the ball and the goalie needs to trust that the defensive players will do their best to
keep the ball away from the goal.
Productive teams also need to trust in each other’s abilities. Designers need to trust that the
Requirements were captured properly. Developers need to trust that the Design was done
properly. Having this trust allows the team members to focus on their aspect of the project and
not have to question all of the other information.
Another key to teamwork is to know where the other team members are located across the
field. This allows whoever has the ball to get it to the appropriate person when they are ready to
receive it. This results in proper handoffs between team members.
4. Coaching
The coach is critical to the success of the team. Their job is to keep the team focused and
motivated to make goals. They see the entire field and can provide valuable insight to the players
who are focused on their part of the game. This is why the coach needs to be observant and
engaged in what is going on during the game.
The coach needs to have the respect of the team members. Yelling from the sidelines is not a very
effective technique for motivating team members. Eventually, they stop listening to the coach
and do things however they want to do them.
Another effective technique of the coach is the half-time talk. This is when the coach motivates
the team during the middle of the game. If the game is going well, they praise the team but
remind them that the game is not over yet. If the game is not going well, they motivate the
players and formulate a new plan. Project Managers shouldn’t wait until ‘half-time’ but should
always be looking to motivate their team members.
5. Proper Training
Proper training also results in a higher probability of success. This is because the team members
have practiced their skills and are not learning to pass the ball for the first time during a critical
game.
Conclusion
Projects can be compared to soccer games in how they are run. Team members need to spread
the field, run without the ball, trust in each other, practice their skills and have a good coach.
When all goes well, the team can make their goals. I will leave it up to you, the PM, to determine if
they can pull their shirts over their heads and run around the field once this happens.
About the Author

Kerry Wills has worked as a Consultant and a Project Manager for Fortune 500 companies on
multi-million dollar technology projects since 1995. During that time, he has gained experience in
several capacities; as a Program Manager, Project Manager, Architect, Developer, Business Analyst,
and Tester. Having worked in each of these areas gives Kerry a deep understanding of all facets of
an Information Technology project. Kerry has planned and executed several large projects as well
as remediated several troubled projects.
Kerry is a member of Mensa and has a unique perspective on project work, resulting in eight
patents, published work in project management journals and books, and speaking engagements
at over twenty Project Management conferences and corporations around the world. Kerry is a
passionate speaker who has a reputation for delivering entertaining presentations combined
with vivid examples from his experiences.
Read Kerry’s blog at http://kerrywills.wordpress.com
About ExecutiveBrief
About ExecutiveBrief
Manage better. Improve performance. Refine processes.
An online periodical for technology managers and business leaders, ExecutiveBrief provides you
with quality original content on following topics:
Software Development – Learn about the innovations in the industry, best practices and new
technologies.
Outsourcing – Discover the latest industry trends and strategies for success.
Agile – Find out about Agile methods and how to implement Agile practices adding value to your
business.
SaaS/Cloud – Find out how to save costs and increase competitive advantage of your business
with deployment of Software-as-a-Service and Cloud computing.
Project Management – Learn how to solve and avoid problems in project management, discover
the leadership skills necessary for making any project team efficient.
Process Improvement – Stay on track with recent developments in process improvement,

discovering how to establish successful business processes to increase your ROI.
Risk Management – Avoid and manage everyday risks in technology business, learn from the
examples of successful risk managers.
With a monthly newsletter including the best published articles and blogs, ExecutiveBrief brings
the latest trends and information in the IT industry and accompanying opinions from our pool of
industry experts directly to your inbox. More articles, blogs and white papers could be found at
www.executivebrief.com.
ExecutiveBrief
730 SW 4th Street, Suite 3
Cape Coral, FL 33991
USA
editorial@executivebrief.com
www.executivebrief.com

A Technology Business Guide To Success

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Technology Business Guide To Success

Uploaded by

Copyright:

Available Formats

A Technology Business

A Technology Business Guide to Success

2 A Technology Business Guide to Success: 30 Ideas You Can Use Now!

Techniques for Successful Software Product Management 10

Business Process Design using Agile Concepts 20

Managing Project Risk: What’s New? 25

Market Segments in Customer-Centric Product Development Model 29

The Importance of Software Requirements for Superior Software 34

The Role of the Software Architect in Applications and Systems Development 37

The High Costs of Building the Wrong Product 41

Business Process Improvement is a Strategic Necessity 44

Are On-Demand Applications Right for Your Business? 58

Six Things for CIOs to Consider Before Moving to Cloud Computing 61

Will Project Managers Have Their Heads in the Cloud? 64

Business Analysts Mitigate Agile Project Risks 73

Introducing Agile Development? Move Gradually! 86

Evolving from Traditional Project Management to Agile 95

How to Scrum 102

Agile Transformation Guidelines: Avoiding Pitfalls 109

Managing Customer Expectations in IT Outsourcing 114

Outsourcing is Not a Slam Dunk 119

Software Development Outsourcing: Get Control of Cultural Differences 127

Project Management 133

Value Triple Constraint: How to Evaluate Project Value Delivered 137

Why Project Scheduling Must Not Become an Extinct Science 144

Build Your High-Performance Virtual Team: 7 Key Steps 155

Common Project Management Hurdles and the Challenge of Change 158

How to be a Project Goal Scoring Champion 161

About ExecutiveBrief 164

4 A Technology Business Guide to Success: 30 Ideas You Can Use Now!

Stay tuned for new exciting developments in 2011!

6 A Technology Business Guide to Success: 30 Ideas You Can Use Now!

The Differences between Usability and User

The rapid growth of RIA technology into the

Somewhat in contrast, user experience

Perhaps the simplest way to distinguish the two would

8 A Technology Business Guide to Success: 30 Ideas You Can Use Now!

The article was originally published at InsideRIA

About the Author

Techniques for Successful Software Product

It’s easy to confuse the disciplines of project

10 A Technology Business Guide to Success: 30 Ideas You Can Use Now!

What Is Software Product Management?

To clearly assign responsibilities, there should be three distinct managerial roles:

12 A Technology Business Guide to Success: 30 Ideas You Can Use Now!

Figure 2: The Results of Insufficient Product Management

4+1 Product Management Best Practices

1. Install an Effective Core Team

2. Enforce the Product Life Cycle

3. Evaluate Needs and Requirements

14 A Technology Business Guide to Success: 30 Ideas You Can Use Now!

4. Assure a Dependable Portfolio

The “+1”: Evolve Your Product Management

Figure 3: The Software Product Management Framework

16 A Technology Business Guide to Success: 30 Ideas You Can Use Now!

1. Behave like an embedded CEO.

The Business Value

Growing an organization’s product management discipline requires good change management

18 A Technology Business Guide to Success: 30 Ideas You Can Use Now!

About the Author

Business Process Design using Agile Concepts

Have you heard the news?

“60% of all software development projects fail to

Gain more insights from competitive analysis.

Make sure you have a shared understanding

Documenting the current process to be analyzed.