Professional Documents
Culture Documents
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.
Table of Contents
Introduction 5
Software Development 6
The Differences between Usability and User Experience 7
Software-as-a-Service 51
Cloud Computing Reality Check 52
Agile 68
Agile Removes Limitations 69
The Marriage of Lean, Scrum and Extreme Programming (XP): How to Align Agile Across an
Organization 77
www.executivebrief.com 3
Table of Contents
Was Deming Right About Quality Management and Project Outcomes? 149
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.
ExecutiveBrief Team
www.executivebrief.com 5
Software Development
SOFTWARE DEVELOPMENT
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.
www.executivebrief.com 7
Software Development
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.
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.
www.executivebrief.com 9
Software Development
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
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.
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
www.executivebrief.com 11
Software Development
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.
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.
www.executivebrief.com 13
Software Development
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.
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.
www.executivebrief.com 15
Software Development
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).
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:
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.
www.executivebrief.com 17
Software Development
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.
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
www.executivebrief.com 19
Software Development
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.
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.
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:
www.executivebrief.com 21
Software Development
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.
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.”
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).
www.executivebrief.com 23
Software Development
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.
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.
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
www.executivebrief.com 25
Software Development
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.
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.
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.
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.
www.executivebrief.com 27
Software Development
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.
www.executivebrief.com 29
Software Development
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.
www.executivebrief.com 31
Software Development
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.
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.
www.executivebrief.com 33
Software Development
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.
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.
www.executivebrief.com 35
Software Development
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.
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
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
www.executivebrief.com 37
Software Development
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
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
www.executivebrief.com 39
Software Development
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.
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
www.executivebrief.com 41
Software Development
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.
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.
www.executivebrief.com 43
Software Development
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.
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:
www.executivebrief.com 45
Software Development
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
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.
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
www.executivebrief.com 47
Software Development
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.
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.
Copyright ©2009 – 2010 Gina Abudi. All Rights Reserved Worldwide. http://www.GinaAbudi.com
http://www.PeakPerformanceGroup.com
www.executivebrief.com 49
Software Development
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
www.executivebrief.com 51
Software-as-a-Service
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.”
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.
Software-as-a-Service
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.
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
www.executivebrief.com 53
Software-as-a-Service
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.
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:
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.
www.executivebrief.com 55
Software-as-a-Service
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
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.
www.executivebrief.com 57
Software-as-a-Service
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
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.
www.executivebrief.com 59
Software-as-a-Service
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
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.
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?
www.executivebrief.com 61
Software-as-a-Service
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.
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.
www.executivebrief.com 63
Software-as-a-Service
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
www.executivebrief.com 65
Software-as-a-Service
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.
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
www.executivebrief.com 67
Agile
AGILE
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:
www.executivebrief.com 69
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!
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.
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]
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).
www.executivebrief.com 71
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.
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:
In reality, business analysts are not “agile road blocks”, but resources who agile practitioners can
put to work.
www.executivebrief.com 73
Agile
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.
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.
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.
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
www.executivebrief.com 75
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.
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.
www.executivebrief.com 77
Agile
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.
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.
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):
www.executivebrief.com 79
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 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:
www.executivebrief.com 81
Agile
XP contains a lot of similar Scrum practices with the engineering elements that Scrum is
traditionally missing.
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.
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.”
www.executivebrief.com 83
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.
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
www.executivebrief.com 85
Agile
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
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.
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.
www.executivebrief.com 87
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.
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.
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.
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.
Figure 1 – The Iron Triangle At this stage, we have introduced estimating the product
www.executivebrief.com 89
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.
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 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.
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.
www.executivebrief.com 91
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.
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.
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.
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.
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
www.executivebrief.com 93
Agile
trust in the team is established – which again is difficult to do until the initial obstacles have been
overcome.
www.executivebrief.com 95
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.
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
www.executivebrief.com 97
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.
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.
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.
www.executivebrief.com 99
Agile
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 ‘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.
100 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Evolving from Traditional Project Management to Agile
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.”
www.executivebrief.com 101
Agile
How to Scrum
How to bring scrum stakeholders, product owners and teams together to produce better backlog,
release and sprint results.
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.
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
102 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
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.
www.executivebrief.com 103
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
104 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
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.
www.executivebrief.com 105
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
106 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
How to Scrum
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.
Dan is a transformation agent who helps organizations change themselves through application
www.executivebrief.com 107
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.™
108 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Agile Transformation Guidelines: Avoiding Pitfalls
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
www.executivebrief.com 109
Agile
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.
110 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Agile Transformation Guidelines: Avoiding Pitfalls
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
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
www.executivebrief.com 111
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.
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.
112 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Agile Transformation Guidelines: Avoiding Pitfalls
Learn more: see VersionOne.com, Rallydev.com, and AgileZen.com for more details the tools
mentioned.
www.executivebrief.com 113
Agile
114 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Managing Customer Expectations in IT Outsourcing
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.
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.”
www.executivebrief.com 115
Agile
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).
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
116 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
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.
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.
www.executivebrief.com 117
Agile
118 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Outsourcing is Not a Slam Dunk
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.
www.executivebrief.com 119
Agile
Establishing a clear objective that outsourcing will serve for your business is a great beginning to
this process.
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.
120 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Outsourcing is Not a Slam Dunk
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.
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,
www.executivebrief.com 121
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.
“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.
122 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Outsourcing is Not a Slam Dunk
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.
www.executivebrief.com 123
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.
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.
124 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Outsourcing is Not a Slam Dunk
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.
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.
www.executivebrief.com 125
Agile
126 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Software Development Outsourcing: Get Control of Cultural Differences
Introduction
Why does this occur? And what are additional obstacles besides the obvious technical issues?
Here are some obvious common barriers to communication with other cultures:
Language
General Education Level
Time Difference
Nationality Specific Traits
www.executivebrief.com 127
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.
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)
Tend to multi-task.
Open-door policies.
Take calls in meetings.
Typical USA.
Monochronic:
Sense of orderliness.
128 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Software Development Outsourcing: Get Control of Cultural Differences
Tend to be conservative.
Relate to a more traditional way of doing things.
Long historical traditions include Britain, China and Japan.
Present-oriented societies:
Future-oriented societies:
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:
www.executivebrief.com 129
Agile
Non-Western:
Time is plentiful.
Punctuality, deadlines not important.
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”.
130 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Software Development Outsourcing: Get Control of Cultural Differences
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.
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
www.executivebrief.com 131
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.
132 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Software Development Outsourcing: Get Control of Cultural Differences
PROJECT MANAGEMENT
www.executivebrief.com 133
Project Management
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
134 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
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.
www.executivebrief.com 135
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.
136 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Value Triple Constraint: How to Evaluate Project Value Delivered
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
Value delivered is a function of the Scope of the business opportunity and of our Capability to
identify, decide and deliver to the opportunity.
www.executivebrief.com 137
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.
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.
Realized Value
Project Cost
Decision Opportunity Cost
Identification Opportunity Cost
138 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Value Triple Constraint: How to Evaluate Project Value Delivered
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:
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
www.executivebrief.com 139
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.
To reduce risk on a single project, we should continuously update the Value Profile, not just the
costs. This would include:
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.
140 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Value Triple Constraint: How to Evaluate Project Value Delivered
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.
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.
www.executivebrief.com 141
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.
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.
142 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Value Triple Constraint: How to Evaluate Project Value Delivered
Web: http://www.PerformanceInnovation.com
Email: ABaratta@PerformanceInnovation.com
www.executivebrief.com 143
Project Management
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.
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”...
144 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Why Project Scheduling Must Not Become an Extinct Science
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.
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
www.executivebrief.com 145
Project Management
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.
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.
146 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
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.
www.executivebrief.com 147
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.
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.
148 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Was Deming Right About Quality Management and Project Outcomes?
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.
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.
www.executivebrief.com 149
Project Management
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.
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.
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
150 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Was Deming Right About Quality Management and Project Outcomes?
stakeholders, understanding their business objectives in order for us to provide the deliverable
that best meets their changing needs.
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.”
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.
www.executivebrief.com 151
Project Management
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.
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
152 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Was Deming Right About Quality Management and Project Outcomes?
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.
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.
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.
www.executivebrief.com 153
Project Management
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.
J. Alex Sherrer is the author of the Project Management Road Trip for the Project Management
Professional (PMBOK, 4th Ed.).
154 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Build Your High-Performance Virtual Team: 7 Key Steps
www.executivebrief.com 155
Project Management
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.
156 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
Build Your High-Performance Virtual Team: 7 Key Steps
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.
www.executivebrief.com 157
Project Management
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
158 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
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
www.executivebrief.com 159
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.
160 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
How to be a Project Goal Scoring Champion
Soccer Match
www.executivebrief.com 161
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.
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.
162 A Technology Business Guide to Success: 30 Ideas You Can Use Now!
How to be a Project Goal Scoring Champion
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.
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.
www.executivebrief.com 163
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.
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
164 A Technology Business Guide to Success: 30 Ideas You Can Use Now!