A Technology Business Guide to Success

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

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

A Technology Business Guide to Success30 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.

http://www.softserveinc.com/

3www.executivebrief.com

Table of ContentsIntroduction 5

Software Development 6

The Differences between Usability and User Experience 7

Techniques for Successful Software Product Management 10

Business Process Design using Agile Concepts 20

Managing Project Risk: What’s New? 25

Market Segments in Customer-Centric Product Development Model 29

The Importance of Software Requirements for Superior Software 34

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

The High Costs of Building the Wrong Product 41

Business Process Improvement is a Strategic Necessity 44

Software-as-a-Service 51

Cloud Computing Reality Check 52

Are On-Demand Applications Right for Your Business? 58

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

Will Project Managers Have Their Heads in the Cloud? 64

Agile 68

Agile Removes Limitations 69

Business Analysts Mitigate Agile Project Risks 73

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

Introducing Agile Development? Move Gradually! 86

Evolving from Traditional Project Management to Agile 95

How to Scrum 102

Table of Contents


Agile Transformation Guidelines: Avoiding Pitfalls 109

Managing Customer Expectations in IT Outsourcing 114

Outsourcing is Not a Slam Dunk 119

Software Development Outsourcing: Get Control of Cultural Differences 127

Project Management 133

Five Pillars of Practical Project Management 134

Value Triple Constraint: How to Evaluate Project Value Delivered 137

Why Project Scheduling Must Not Become an Extinct Science 144

Was Deming Right About Quality Management and Project Outcomes? 149

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

Common Project Management Hurdles and the Challenge of Change 158

How to be a Project Goal Scoring Champion 161

About ExecutiveBrief 164

Table of Contents

Introduction


IntroductionExecutiveBrief 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 [email protected] and we’ll try incorporating your suggestions as well. If you are an industry expert and would like to contribute to Executive Brief, please send your resume and samples of work.

Stay tuned for new exciting developments in 2011!

ExecutiveBrief Team

http://www.executivebrief.com

mailto:editor%40executivebrief.com?subject=

Software Development


SOFTWARE DEVELOPMENT

The Differences between Usability and User Experience


The Differences between Usability and User ExperienceLearn about the differences between the Usability and User Experience which are rapidly gaining popularity but often confused or thought to be synonymous.

The rapid growth of RIA technology into the lives of every day people just a few years ago has carried both the usability and user experience industries to a new high in popularity. The success of software (particularly on the web) has driven both of these terms into our vernacular, and yet they are still often confused or thought to be synonymous. This post is meant to help those new to the field or unfamiliar with the intricacies of design to understand the differences between the terms.

Usability refers to the ease with which a user can accomplish his or her goals using any tool. Coming from the field of human factors engineer, usability has been applied to software in the fields of human computer interaction and includes many important ideas from psychology and statistics. Usability is fundamentally qualitative but involves the heavy application of quantitative data to identify areas of weakness and suggest improvements. The study of usability often focuses on performing extensive tests with large groups of individuals, sometimes involving in depth techniques like eye tracking to determine how users interact with interfaces and any areas in which they get lost. Highly usable interfaces are often lauded for being intuitive, simple or extremely learnable.

Somewhat in contrast, user experience refers to the way a user perceives his or her interaction with a system. User experience design encompasses both interaction design and visual design and seeks to promote an interface that is pleasing to the user. The study of user experience often focuses more on the psychological impact of interacting with the system than pure usability does, and user experience experts will spend their time performing both ethnographic and psycho-graphic research to construct

Usable for certain.



their interfaces. User experience design is more qualitative than usability, though the two are not necessarily exclusive. For instance, often times user experience experts turn their designs over to usability experts to test and validate them in the field.

By far the easiest (and probably most over-cited, please forgive me) to distinguish these two comes on lauded usability expert Jakob Nielsen’s homepage, useit.com. Jakob has dedicated a lifetime to the study of usability, and his website represents a page that is extremely easy to interact with. Everything is front and center, easily searchable, with important ideas stressed through bold text. Yet despite its high level of usability, the lack of interesting layout, design, or even typography makes the site rather boring and feel uninspired. I can accomplish my goals here easily, but I probably won’t have much fun in the process.

On the flip side, let us consider interfaces which receive a high rating in user experience but perhaps a low one in usability. A good user experience is one in which the user is pleased with their interaction, but this says nothing about the user’s ability to achieve their goals. While these two things are usually well aligned this is not always the case, and sometimes the most successful interfaces are those that can make difficult systems so enjoyable that even failing to achieve ones goals is still fun. My favorite example for this is, to the detriment of my online reputation and popularity with a large portion of the internet, Apple. Apple does an amazing job producing software that is fun to interact with but from a usability perspective much of it is atrocious. The iPhone is mired in confusing interfaces requiring a high number of clicks to achieve any goal, as anyone who has tried to use the “Maps” app for directions while driving can attest. If you need farther proof, just try and explain how to use iTunes or the app store to your grandmother. It’s nearly impossible to understand without extensive time spent learning the interface and this is more or less the definition of low usability. Yet Apple’s great reputation in interface design is not entirely without merit, as their attention to user experience is second to none. Failing on the iPhone is more enjoyable than succeeding on a Blackberry.

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

I dare you try this while driving.

I take that back - please never try to use this while driving.

The Differences between Usability and User Experience


research is surely scientific. At the end of the day all that is really important is to understand the distinction between the two terms and to realize the massive importance of both in the design of good interfaces.

Credit for some of the ideas in this post goes to Timothy J. Wood, who let me listen in while he explained the difference between usability and user experience this morning.

The article was originally published at InsideRIA

About the Author

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

http://www.insideria.com/2010/01/the-difference-between-usabili.html



Techniques for Successful Software Product ManagementConcrete practices that boost your organization’s software product management performance.

It’s easy to confuse the disciplines of project manager and product manager. Simply put, the development of the product or service falls to the project manager, while the market success of software and system products depends on the skills and competence of the product manager. This article provides an overview of software product management and the role of a product manager, and describes concrete practices that can boost an organization’s software product management and thus the success rate of products in terms of predictability, quality, and efficiency.

Imagine loggers in a forest. They work hard and cut tree after tree. It is a huge physical effort and their foreman drives them hard to stay on schedule. He wants to cut a certain number of trees per day and provides the workers with all they need to achieve this objective. Suddenly the client shouts, “you cut down the wrong trees!” Despite all the hard work of the foreman and his team, they did not manage to deliver the intended customer expectation. Sound familiar? Indeed, this is what I’ve observed with many software products. Organizations are pushed to the extreme to be ever more efficient and create products at a low cost, but when it hits the market and sales are lower than expected or customers demand several changes during the development process, margins are dramatically reduced from initial targets.

Successful product management means delivering the right products at the right time for the right markets. Naturally, the success of a product depends on many factors and stakeholders. However, it makes a big difference when a person is empowered to manage a product from inception to market and evolution – and the same person is held accountable for the results. This is the product manager.

At Vector Consulting Services, we have learned from experience with many clients in different industries that success comes from anticipating and meeting the customer’s needs together with being on time and on budget. Technical product development – such as for automotive components, communication solutions, defense systems, or IT infrastructure – traditionally focuses on the project perspective and operationally executing a set of given constraints within

Techniques for Successful Software Product Management


the triangle of content, budget, and time. Often, it becomes clear too late that customer needs were different from what is built.

Project execution can be rather easily improved by means of CMMI®. Today, there are a lot of exciting results from optimizing projects in terms of cost and cycle time [1, 2]. However, the software product management responsibility and underlying processes remain vague. I often see product definition, road mapping, and marketing decoupled from the engineering project-related processes, which creates deficiencies and overheads such as heavy changes in requirements and missed market opportunities. It is like the loggers: The project runs well, but with the wrong results.

While an organization can embark on the general principles of product management [3], not much specific guidance is available for software product management. This article will provide a small introduction and tutorial on software product management.

What Is Software Product Management?

Product management is the discipline and business process governing a product from its inception to the market or customer delivery and service in order to generate the largest possible value to a business. A product is a deliverable that has a value and provides an experience to its users. It can be a combination of systems, solutions, materials, and services delivered. Product management provides leadership to activities such as portfolio management, strategy definition, product marketing, and product development.

Often, the roles of product manager, project manager, and marketing manager are unclear in their distinct responsibilities. To successfully define, engineer, produce, and deliver a product, these three roles need to be clarified [3, 4, 5]. Figure 1 provides an overview of an archetypical product life cycle and shows how different projects integrate towards an end-to-end view of the product. It highlights the differences between managing a project and managing a product. The project is a temporary endeavor undertaken to create a product. The project manager focuses on delivering one specific product or release while meeting time, budget, and quality requirements. The product manager looks to the overall market success and evolution of this product together with its subsequent releases, related services, etc.

Figure 1: Software Product Management Spans the Entire Product Life Cycle



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

� The product manager leads and manages one or several products from inception to phase-out in order to maximize business value. They work with marketing, sales, engineering, finance, quality, manufacturing, and installation to make the products a business success [3]. They have business responsibility beyond the single project. They determine what to make and how to produce it, and are accountable for business success within an entire portfolio. They approve the roadmap and content and determine what and how to innovate, and are responsible for the entire value chain of a product following the life cycle, asking: What do we keep, what do we evolve, and what do we stop?

� The project manager determines how to best execute a project or contract. They ensure that the specific project is executed as defined and are accountable for business and customer success within a contract project. They manage the project plan and its execution and ask: How do we get all of this accomplished?

� The marketing manager determines how to sell a product or service in order to create a customer experience. They are accountable for market and customer success and have a profound understanding of customer needs, market trends, sales perspectives, and competitors. The marketing manager communicates the value proposition to sales and customers, drives the sales plan and execution, and asks: What markets will we address?

One might argue that in many organizations, one or several of these roles are laid out differently and might simply be coordinating based on directions received from management. While this has certainly been observed, such organizations often encounter interface and responsibility battles and have a lack of ownership as a result. These three roles are necessary and need to be empowered – and held accountable for results. This not only stimulates motivation, but also facilitates faster and more effective decision making in a company [2, 3].

Over the years, Vector Consulting Services has investigated root causes of such insufficient product management and its impacts on hundreds of technical products with different origins, development paces, and sizes [1, 4]. Figure 2 provides an example of how product management failures cause rework, scope creep, and delays. Insufficient product management typically lacks vision, has an unclear market and business understanding, and doesn’t involve the right stakeholders (see the left side of Figure 2). This leads to initial symptoms such as a conflict of interest on priorities and contents and incomplete requirements. From here, it’s a vicious circle with changes that necessitate rework, which in turn causes delays, which in turn causes scope creep – and so on. Poor product management causes insufficient project planning, continuous changes in the requirements and project scope, configuration problems, and defects. The obvious (yet late) symptoms are more delays and overall customer dissatisfaction due to not keeping commitments or not getting the product they expect (the right side of Figure 2). Being late with a product in its market has immediate and tremendous business impacts [6, 7, 8]. In the contract business, this often means penalties and, in practically all markets, it reduces customer loyalty and overall sales returns.



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

4+1 Product Management Best Practices

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

1. Install an Effective Core Team

Often, different stakeholders have un-aligned agendas that make the project late and cause lots of overhead and rework. The first thing to do is formally create a core team with the product, marketing, project, and operations managers for each product (release) and make them fully accountable for the success of a product. These people represent not only the major internal stakeholders in product or solution development, but also sufficiently represent different external perspectives. The core team leads the product development in all its different dimensions. They typically meet once a week to discuss all open issues, risks, and relevant aspects of the product.

Figure 2: The Results of Insufficient Product Management



Decisions are taken and implemented by the respective function. I suggest announcing and making this core team operational as early as possible in the product life cycle, but certainly when the product or release is defined. The success factor is to give this core team a clear mandate to own the project. I have observed that the most need for active support is in the building of an effective core team that agrees that they have to steer the course together. Too often, we face silo organizations in marketing, where product management and engineering don’t work together. In many cases, this means the necessity is not only to build teams, but also to train and coach employees and to adjust annual targets and performance management. As we often realize, culture changes when targets are adjusted.

2. Enforce the Product Life Cycle

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

3. Evaluate Needs and Requirements

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



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

4. Assure a Dependable Portfolio

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



The “+1”: Evolve Your Product Management

Just having these four software management practices distilled and processes agreed upon is not sufficient in order to improve the product management culture. Often, I’ve seen organizations where product managers complain about a lack of empowerment and remain in an observer role. The truth is that they simply don’t have the right competencies to be empowered as a mini-business owner; this leads to the wrong people in wrong positions. To achieve a true culture change, I strongly recommend competence building for all product managers across an organization. This means change management and closely working with product managers to help them grow. Such individualized and focused competence management strengthens individual product managers and helps them achieve their missions. The equation is simple: Competence and leadership enforced from the bottom up in each project yields better products, which grows motivation and improves the overall performance.

Our software product management framework was shaped by working with hundreds of product managers worldwide in different industries [4, 5]. Figure 3 shows the product management framework in a simplified format. The top shows a product life cycle as most companies today have it formally up and running. Processes are derived from best practices and underline the formal content of product management in an organization. The middle section of the figure shows the typical processes that a product manager is responsible for, or is at least heavily involved with. Finally, what is derived from these processes (shown on the bottom of the figure) are the competency needs of an organization’s product management. While there are overlaps across companies, focus areas differ (e.g., a software service provider has different focus areas in this framework than an automotive supplier).

Figure 3: The Software Product Management Framework



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

Product managers often ask what they can do to deliver better results. Here are 10 ways to personally grow as a product manager:

1. Behave like an embedded CEO.

2. Drive your strategy and portfolio from market and customer value.

3. Be enthusiastic about your product.

4. Have a profound understanding of your markets, customers, and portfolio.

5. Measure your contribution on sales (top-line) and profits (bottom-line).

6. Periodically check assumptions such as business cases.

7. Take risks and manage them.

8. Foster teamwork based on Lean processes.

9. Insist on discipline and keeping commitments.

10. Be professional in communication, appearance, and behavior.

Having observed hundreds of industry projects from domains such as small software applications and services, embedded systems to large communication and IT systems, I strongly suggest applying the four software product management practices in parallel; they depend on each other. Their combined use will significantly reduce delays and thus improve market performance. These four practices are applicable in different organizations and industries. They are tangible and can be formally introduced to projects during the launch period, thus reducing the impact change and allowing an organization to see the growing benefits early in their projects.

The Business Value

Does better software product management mean better business performance? At Vector Consulting Services, we have performed a root cause analysis of hundreds of products that underperformed and found similar causes reappearing. Root causes included business cases



that were never re-evaluated, unbalanced portfolios that strangulate new products, insufficient management of new releases and service efforts, and a lack of vision causing requirements to continuously change. This is underlined by observations such as in [6], which indicates that the top 20 percent of enterprises deliver 79 percent of new products on-time, while the average enterprise delivers only 51 percent of on-time projects. The same holds true for efficiency: We found that with a requirements change rate beyond 20 percent in a project, productivity falls, and as such, business performance [1].

Improved product management has a profound positive impact on overall business. For instance, strengthening the product management role at Alcatel-Lucent showed that duration (time to market), schedule adherence, and handover quality all improved in a sustainable way. We have been working with hundreds of product managers and achieved a 20 percent per year reduction of delays [1, 4]. Explanatory factors for this positive impact of product management include leadership and teamwork, managing risks and uncertainty, mastering stakeholder needs, and accountability towards agreed business objectives – managed by one empowered person across the product life cycle.

Conclusions

Using the 4+1 method means more ownership, leadership, and motivation in product development teams and at their interfaces. Each of the practices can be applied within a single product line if a company is not yet prepared to introduce them across all product lines. The practices and overall product management framework can be gradually introduced to product lines or business units, thus reducing the change impact. Practitioners in engineering, product management, and marketing accept these practices because they yield concrete performance improvement and stimulate empowered project teams.

Growing an organization’s product management discipline requires good change management to achieve a culture where these practices are used and implemented by teams across the organization, supported by their management, and communicated openly to resolve conflicts.

For improved software production and market success, product management is here to stay. It is not a proxy to arbitrate a variety of conflicting interests, but rather a key business role in an entire company that is empowered to act as a business owner. It provides the basis for success or failure in the product’s development. Or, using our initial analogy: If you do not know which direction to take in cutting the trees, don’t simply start just to show progress. Real progress is what creates a lasting user experience, and this is defined from a product perspective – not ad-hoc during project work in a shouting contest.

Acknowledgement

This article is based on evolving the product manager competence in different companies



worldwide. The 4+1 best practices had been fine-tuned during many discussions at the International Workshop on Software Product Management (IWSPM) series.

References

1. Ebert, Christof, and Reiner Dumke. Software Measurement. New York: Springer, 2007.

2. Reifer, Donald J. “Profiles of Level 5 CMMI Organizations.”Jan. 2007.

3. Gorchels, Linda. The Product Manager’s Handbook: The Complete Product Management Resource. 3rd ed. New York: McGraw-Hill, 2006.

4. Ebert, Christof. “The Impacts of Software Product Management.” The Journal of Systems and Software. Vol. 80, Issue 6: 850-861, June 2007.

5. IWSPM. Proc. from the International Workshops on Software Product Management. 12 Sept. 2006, Minneapolis, and 9 Sept. 2008, Barcelona, Spain.

6. Cooper, Roger G., et al. “Benchmarking Best NPD Practices.” Research-Technology Management. Part I: Jan. 2004: 31; Part II: May 2004: 43; Part III: Nov. 2004: 43.

7. Davis, Alan Mark. Just Enough Requirements Management. New York: Dorset House, 2005.

8. Karlsson, Lena, et al. Challenges in Market-Driven Requirements Engineering – An Industrial Interview Study. Proc. of 8th International Workshop on Requirements Engineering: Foundations for Software Quality. Essen, Germany: 37-49. 9-10 Sept. 2002 .

The article first appeared in CrossTalk, Jan 2009

About the Author

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

mailto:ebert%40vector-consulting.de?subject=



Business Process Design using Agile ConceptsBusiness process design takes a page from the software development playbook. Discover new strategies for better business process design using agile concepts.

Have you heard the news?

“60% of all software development projects fail to meet their goals.”

Of course you’ve heard this. EVERYONE has heard this nugget of wisdom. It starts off presentations, it’s used in consulting pitches, software integrators put it in their marketing materials, and IT departments promise it won’t happen to them (or you). Here’s the problem: it’s probably wrong. I believe that, in fact, closer to

80% of enterprise software development projects fail to meet goals. The key is — it is a specific type of software project that nearly always fails. The type of development project that nearly always fails is the “old school” waterfall-type project. The kind that starts out with requirements crafted in excruciating detail, progresses to multiple layers of sign-off, is developed in several phases — each with their own system, unit, and user acceptance testing — and eventually finishes with a final result that doesn’t fit the needs of a business that has long since moved on. Over the years I’ve seen software that was released that no longer fits an evolved business model, software that missed huge, key requirements, and software that was released just in time for an acquisition that changed the entire business environment.

Whew. I’m frustrated just thinking about it. Luckily, the software development industry (mostly) figured out that this was a problem quite while ago. Most successful projects today — especially externally facing consumer projects — follow a very different trajectory than the development projects of ten or even five years ago, emphasizing tighter contact with the customer, faster development cycles, and the testing of smaller chunks of code.

So what does this have to do with business process design?

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

Business Process Design using Agile Concepts


1. Document the old process in mind-numbing detail (about two weeks’ worth of time)

2. Identify the issues in the old process (a week here)

3. Design phases for a new process (another week)

4. Design the details for the new process (easily four weeks)

5. Implement the whole thing as one giant project (I don’t even want to guess...)

6. Hope it works (and that the design is still relevant after so much time has passed)

And surprise, like the outmoded techniques for software design, the process design projects conducted in this manner also have an extremely high “failed to achieve results” rate — even worse than for IT projects in my experience. I speak from experience — this is exactly the way we used to perform process redesign work in the past. Redesigning a process using this “technique” was tedious and frustrating, both for us and for our clients. And, it was tough to achieve the desired result.

But it doesn’t have to be this way.

Process redesign projects don’t have to be lumbering, slow, painful exercises that rarely succeed in achieving their goals. By learning the hard-won lessons of software developers, you can dramatically increase your chances for success in your process redesign project.

When software development moved past traditional waterfall-style development, a new way of thinking emerged called “Agile Development.” Agile development stresses speed over perfection, rapid development of small bits of functionality, and testing of all deployed code. How can this be used for business process improvement? Here are three of the main “agile” concepts and how you can use them to improve processes more rapidly and with a much higher success rate:

Lesson #1: Minimum Viable Process (MVP)

One of my favorite phrases is “the perfect is the enemy of the good,” and nowhere is this more true in the design of business processes. In the past, businesses undergoing process redesign — whether they called it TQM, BPR, or Six Sigma — all made a similar mistake. They took far too long to develop the process, hoping for a “perfect” final design that met all objectives and avoided all constraints. As someone who has fallen prey to this seductive path myself, I can tell you with 100% certainty that there is no “perfect process” waiting around the corner, there is no “magic bullet,” there is no single “correct solution.” The process that is actually deployed and is actually in use is almost always better than that “perfect” process that exists only on a Visio diagram hanging on the wall. Business needs and goals change so quickly these days that you simply cannot afford to spend months designing the ultimate business process. By taking an extended period of time to develop our business processes, we risk a final product that was “perfect” for the situation that existed several months ago — but useless in today’s environment.



So how do we reconcile the need to improve processes with the need to move quickly and get something that improves the situation up and running? One solution is called the “minimum viable process” or MVP. The concept is simple: design the simplest, most basic process that will get the job done and iterate from there. Ok... So what does THAT mean? It means that you dispose of just about everything that isn’t directly related to delivering the output of the process until you can prove that without the pieces that are left, the process simply cannot function. It means that you design the process without the multiple re-work, validation, approval, and wait state loops that dominate most processes today. Treat each process checkpoint or approval state as a design failure — a process step that exists only because the process itself is inherently flawed in even needing a checkpoint — and try to design that step away. Obviously you won’t be able to eliminate every single check & balance step in your process, but minimize them and see what happens. The key with the MVP design is that you need to get a new process out, up, and running as quickly as possible to test its performance in the real world. Those super-complex, “perfect” processes will need to reach the real-world stage at some point — wouldn’t you rather have spent two-thirds less time in process design when you find out that your process has major flaws that must be corrected? Use the MVP as your initial test platform to challenge your assumptions and ideas about the new way of doing work. Then, use the next concept — Continuous Deployment — to make the process better fit the goals of the business.

Lesson #2: Continuous Development & Deployment

ANY process that you design — whether you spend days, weeks, or months building it — will have problems. You can count on it. I’ve designed and implemented many new processes over the past 15 or so years, and I have yet to see a single process that, once “in the wild,” didn’t have to change to some degree. With this being the situation, the key to a successful process design implementation is the pace at which you are able to effectively change the process design in response to the issues that you identify. Often, organizations take an “implement once and forget it” approach and unfortunately this results in an overall poor redesign result (part of that 60%). You have to find the process flaws and fix them quickly.

So how do you remedy this situation, recognize issues with processes and make changes that will better meet the design goals? The best practice for this is called “continuous deployment” and has grown in popularity in the software development community over the past few years. Here’s how it works in the software world:

1. you work closely with the “customer” to understand and build the software

2. you release the software in little “chunks” of functionality

3. you observe and fix

4. you release again

This all happens very quickly. In fact, one of the leading advocates of continuous deployment,

Business Process Design using Agile Concepts


Eric Ries, talks about how his company would deploy commercial software to the customer base multiple times per day. He stated that if each engineer didn’t deploy at least every few days, it meant that something was wrong. You can make the same continuous development & deployment principle work for you when redesigning business processes. Adopt the philosophy that every day during the design cycle, something, anything, must be “shipped.” It could be a new form for ordering, a prototype of an online database for tracking customer data, or a change to your CRM tool. The key is that you release constantly and learn from what happens. Think small frequent changes, not big delayed changes.

By now you might be thinking “Wait — we can’t do that. What if we get it wrong? We need to perform testing/cost-benefit-analysis/executive review/financial review/legal approval/(insert committee here) review before we do anything. We could hurt the business.” I don’t believe that for a second. The potential for having a small “release” of a business process change — one that you monitor very closely to observe the results — damaging the business irreparably before you see the problem and release a process fix is very low. In fact, I would argue that these small process releases are much easier to monitor and problems are far easier to detect that when you perform one massive release at the end of a process redesign. World-leading design firm IDEO calls the concept of converting risk into smaller, manageable pieces “risk chunking” and uses it to ensure that their new product designs aren’t an “all or nothing” proposition. You want to see risky? Forklift in a massive process implementation after eight or ten weeks of design work and try to identify the issues (or benefits) that are associated with what you just did. Now THAT’S risky!

Of course, if you release a new process or a process change and then ignore it and move on to the next challenge, you’ve missed the point. When performing continuous deployment of process, you must monitor the results. Did it work? Did it cause unintended consequences? The way to tell is through another software technique called “A/B testing.”

Lesson #3: A/B Process Testing

You’ve created the smallest, leanest process possible, you’ve implemented it using continuous techniques, now what? Now you need to test the results. Often, process implementations are treated almost like a bullet to the head — one shot and it’s over. The software world has taught us nothing if not the need for constant review of the effectiveness of each “release.” Imagine software that was released, had bugs, and was never reviewed or fixed. How likely would you be to call that software a success or to recommend it to a friend or colleague? In the software world of agile development, a technique called “A/B testing” or “split testing” is used to determine the implications of a recent release.

Here’s how A/B testing works: you are doing continuous, small deployments so each piece of functionality is relatively easy to understand in terms of its implication to the users. When you deploy this small functionality change (the “A” functionality), you deploy it to a sub-set of the users and compare to the users who are still using the old functionality (the “B” functionality).



Think of it like a small, rapid beta test. This can have huge, beneficial implications for software — think of what would happen if you deployed a new “Buy Now” button to a website but accidentally colored the button the same as the page background. You now have, as Eric Ries says, “a hobby, not a business model.” Obviously, you would prefer to detect an issue such as this sooner, rather than later.

Use the A/B testing concept for your business process changes. Instead of deploying a changed form, website, or process to the entire set of “users,” deploy to a smaller set of test users and compare the differences. Did the new process perform the way you expected? If so, deploy the change to the rest of the process users. If not, go back, re-develop that part of the process and re-deploy. Continuous development and A/B testing are a tightly linked loop of design, development, deployment, testing, and re-development. Just remember that A/B testing without continuous deployment means that mistakes will be out in the wild much longer than they should and continuous deployment without A/B testing means that issues may go unnoticed for far too long.

We need to break out of that old cycle of developing monolithic processes only to have them fail to produce the results we anticipated. In an environment where every dollar counts more than ever, we just cannot afford a 60% plus failure rate in process redesign. It not only costs us time and money, but also credibility with employees. Use the lessons from software development and build lean, minimum viable processes, deploy them quickly and continuously, and test the results against the old process. Everything you implement won’t be a success, but when a mistake does occur, you will find it quickly and be able to rapidly make the changes necessary to succeed when you implement the next time around.

About the Author

Kevin M. Smith is a co-founder and managing partner at NextWave Performance LLC. Prior to joining NextWave Performance, Kevin held the position of Vice President at Retreon Inc. where he was responsible for development of process and program management technology and delivery of process management and improvement professional services.

As a Senior Director at Qwest Communications, he led both the Systems Strategy and the Engineering Program Management teams for the National Networks organization. He spearheaded the deployment of new technologies programs and developed innovative web tools used by the corporation to manage as many as 15,000 concurrent projects for more than 6,000 users. A “Six Sigma Black Belt,” Kevin also led corporate process management and improvement initiatives at LCI International and MCI, and served with Booz, Allen Hamilton as a consultant in their Process Improvement practice.

Kevin holds a B.S. in Finance, as well as an M.B.A. in Process Management, both from the University of Maryland, College Park.

Managing Project Risk: What’s New?


Managing Project Risk: What’s New?Plenty. Learn the road to better project risk management through principles, process, people and persistence.

Humans have been undertaking projects for millennia, with more or less formality, and with greater or lesser degrees of success. We have also recognised the existence of risk for about the same period of time, understanding that things don’t always go according to plan for a range of reasons. In relatively recent times these two phenomena have coalesced into the formal discipline called project risk management, offering a structured framework for identifying and managing risk within the context of

projects. Given the prevalence and importance of the subject, we might expect that project risk management would be fully mature by now, only needing occasional minor tweaks and modifications to enhance its efficiency and performance. Surely there is nothing new to be said about managing risk in projects?

While it is true that there is wide consensus on project risk management basics, the continued failure of projects to deliver consistent benefits suggests that the problem of risk in projects has not been completely solved. Clearly there must be some mismatch between project risk management theory and practice, or perhaps there are new aspects to be discovered and implemented, otherwise all project risks would be managed effectively and most projects would succeed.

So what could possibly remain to be discovered about this venerable topic? Here are some suggestions for how we might do things differently and better, under four headings:

1. Principles 3. People

2. Process 4. Persistence

Problems with principles

There are two potential shortfalls in the way most project teams understand the concept of risk. It is common for the scope of project risk management processes to be focused on managing possible future events which might pose threats to project cost and schedule. While these are undoubtedly important, they are by no means the full story.



The broad proto-definition of risk as “uncertainty that matters” encompasses the idea that some risks might be positive, with potential upside impacts, mattering because they could enhance performance, save time or money, or increase value. And risks to objectives other than cost and schedule are also important and must be managed proactively. This leads to the use of an integrated project risk process to manage both threats and opportunities alongside each other. This is more than a theoretical nicety: it maximises a project’s chances of success by intentionally seeking out potential upsides and capturing as many as possible, as well as finding and avoiding downsides.

Another conceptual limitation which is common in the understanding of project risk is to think only about detailed events or conditions within the project when considering risk. This ignores the fact that the project itself poses a risk to the organisation at a higher level, perhaps within a programme or portfolio, or perhaps in terms of delivering strategic value. The distinction between “overall project risk” and “individual project risks” is important, leading to a recognition that risk exists at various levels reflecting the context of the project. It is therefore necessary to manage overall project risk (risk of the project) as well as addressing individual risk events and conditions (risks in the project). This higher level connection is often missing in the way project risk management is understood or implemented, limiting the value that the project risk process can deliver. Setting project risk management in the context of an integrated Enterprise Risk Management (ERM) approach can remedy this lack.

Problems with process

The project risk process as implemented by many organisations is often flawed in a couple of important respects. The most significant of these is a failure to turn analysis into action, with Risk Registers and risk reports being produced and filed, but with these having little or no effect on how the project is actually undertaken. The absence of a formal process step to “Implement Risk Responses” reinforces this failing. It is also important to make a clear link between the project plan and risk responses that have been agreed and authorised. Risk responses need to be treated in the same way as all other project tasks, with an agreed owner, a budget and timeline, included in the project plan, reported on and reviewed. If risk responses are seen as “optional extras” they may not receive the degree of attention they deserve.

A second equally vital omission is the lack of a “post-project review” step in most risk processes. This is linked to the wider malaise of failure to identify lessons to be learned at the end of each project, denying the organisation the chance to learn from its experience and improve performance on future projects. There are many risk-related lessons to be learned in each project, and the inclusion of a formal “Post-project Risk Review” will help to capture these, either as part of a more generic project meeting or as a separate event. Such lessons include identifying which threats and opportunities arise frequently on typical projects, finding which risk responses work and which do not, and understanding the level of effort typically required to manage risk

Managing Project Risk: What’s New?


effectively.

Problems with people

It is common for project risk management to be viewed as a collection of tools and techniques supporting a structured system or a process, with a range of standard reports and outputs that feed into project meetings and reviews. This perspective often takes no account of the human aspects of managing risk. Risk is managed by people, not by machines, computers, robots, processes or techniques. As a result we need to recognise the influence of human psychology on the risk process, particularly in the way risk attitudes affect judgement and behaviour. There are many sources of bias, both outward and hidden, affecting individuals and groups, and these need to be understood and managed proactively where possible.

The use of approaches based on emotional literacy to address the human behavioural aspects of managing risk in projects is in its infancy. However some good progress has been made in this area, laying out the main principles and boundaries of the topic and developing practical methods for understanding and managing risk attitude. Without taking this into account, the project risk management process as typically implemented is fatally flawed, relying on judgements made by people who are subject to a wide range of unseen influences, and whose perceptions may be unreliable with unforeseeable consequences.

Problems with persistence

Even where a project team has a correct concept of risk that includes opportunity and addresses the wider context, and if they ensure that risk responses are implemented effectively and risk-related lessons are learned at the end of their project, and if they take steps to address risk attitudes proactively – it is still possible for the risk process to fail! This is because the risk challenge is dynamic, constantly changing and developing throughout the project. As a result, project risk management must be an iterative process, requiring ongoing commitment and action from the project team. Without such persistence, project risk exposure will get out of control, the project risk process will become ineffective and the project will have increasing difficulty in reaching its goals.

Insights from the new approach of “risk energetics” suggest that there are key points in the risk process where the energy dedicated by the project team to managing risk can decay or be dampened. A range of internal and external Critical Success Factors (CSFs) can be deployed to raise and maintain energy levels within the risk process, seeking to promote positive energy and counter energy losses. Internal CSFs within the control of the project include good risk process design, expert facilitation, and the availability of the required risk resources. Equally important are external CSFs beyond the project, such as the availability of appropriate infrastructure, a supportive risk-aware organisational culture, and visible senior management support.



So perhaps there is still something new to be said about managing risk in projects. Despite our long history in attempting to foresee the future of our projects and address risk proactively, we might do better by extending our concept of risk, addressing weak spots in the risk process, dealing with risk attitudes of both individuals and groups, and taking steps to maintain energy levels for risk management throughout the project. These simple and practical steps offer achievable ways to enhance the effectiveness of project risk management, and might even help us to change the course of future history.

Note: All of these issues are addressed in the book “Managing Risk in Projects” by David Hillson, published in August 2009 by Gower (ISBN 978-0-566-08867-4) as part of the Fundamentals in Project Management series.

About the Author

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

http://www.riskdoctor.com

http://www.riskdoctor.com

mailto:david%40risk-doctor.com?subject=

Market Segments in Customer-Centric Product Development Model


Market Segments in Customer-Centric Product Development ModelA product development expert shares his model for describing the market and market segments which emphasizes the critical customer-centric perspective that product managers need to have.

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

Customer-Centric Market Model

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

Key goals of the model:

� Provide a framework that helps product managers make decisions about products.

� Establish an outside-in bias that encourages product managers to think first about customers and second about implementation.

� Encourage teams to design products that solve real problems that people will pay to solve.

� Support both Agile and Waterfall development processes.

A Model for Markets, Segments, Customers, and Problems

A market can be thought of as the collection of contexts in which you might sell your product. You can split your market into a set of market segments. Each of those segments represents a group of customers, each of whom shares a set of



problems for which they would pay for solutions.

Markets and Market Segments

Market segments are traditionally defined based on aggregate data that makes it easy to operationally address groups of customers. Business-to-business (B2B) and business-to-consumer (B2C) markets are typically divided using the same approach, with a few data sources that are uniquely relevant for each type of company-to-customer relationship.

Larger view of market segmentation approaches

Business-To-Business (B2B)

When defining market segments for B2B products, your customers are companies. Groups of companies are defined, and organizational structures are built around those segmentation models. Different factors and combinations of factors are used to define the different market segments. Common B2B segmentation factors include:

� NAICS Industry Definitions – A standard taxonomy for defining the different businesses in which your customers engage.

� Demographic Data – For companies, this can be number of employees, annual revenue, corporate structure, or other characterizing metrics that are relevant to your product.

� Transaction History – The history of purchases by the company. Absolute magnitude, frequency, and recency of purchases can all be used.

� Geography – Where a particular company is located. While not always correlating with



variation in companies, it may serve as an effective way to “split the work” for internal organization – such as geographic sales teams. This type of segmentation can also help when business rules or policies vary by geographic region – such as tax, policy, and other legal variations that apply either to your company or your customer.

Business-To-Consumer (B2C)

Defining market segments for B2C products typically uses the same approach, with slightly different factors for consideration. Common B2C segmentation factors include:

� Demographic Data – For consumers, this can be household income, age, or other easily measured and aggregated characteristics.

� Transaction History – As with B2B segmentation, the history of purchases by the consumer is considered. Frequency (loyalty), recency, and absolute magnitude (lifetime customer value) of purchases are all usable.

� Geography – Geography can be used for B2C segmentation in the same way that it is used for B2B products. A designated market area (DMA) represents a region of customers that would receive the same broadcast messages, and companies sometimes organize their customers by DMA. Third party companies also provide geographic segmentation based on patterns of similar demographic data that can be statistically associated with a given geography.

� Behavioral Data – As an ecommerce company, you can measure and study the specific user actions of customers on your website, correlate those behaviors with transactional actions, and define groups of customers that “behave the same way” in order to customize their website experience, offer targeted promotions, and otherwise organize engagement and reporting.

� Psychographic Data – Customers that consider purchasing your product for similar reasons; customers who have similar backgrounds, experiences, and perspectives; and customers that share user goals are commonly identified as personas. These personas are archetypes that represent groups of customers. These groupings can be used to segment your market.

Customers

The term customer is ambiguously applied to both buyers and users, and is only accurate when it represents someone who is both the purchaser and the end-user of your product. You should explicitly think about your customers as buyer personas and user personas.

Buyer personas compare products based on their suitability to solve the problems that



the buyer perceives as valuable. User personas value products based on how effectively the products solve their real problems. This is the most important distinction between buyers and users, while both are focused on value, only the end users will realize the value directly.

Market research should be focused on developing personas that represent homogeneous groups of customers, so that you can focus on the problems that each group distinctly faces.

Problems

Problems to be solved for the groups of customers that make up your market segments are what define a market. Kano analysis provides you with the tools to classify these problems, allowing you to make informed decisions about which problems to focus on in your product roadmap.

Kano analysis problem classification

Kano analysis, as originally defined, classifies products in terms of the features or capabilities they provide. The naming originally used by professor Kano (as translated) is slightly different than the terms used above. The change in terminology here provides more clarity,

particularly when applying Kano analysis from a market-perspective (outside-in) versus a feature-perspective (inside-out).

As a market-driven product manager, you should tweak the language of Kano into classification of problems and solutions, because customers value solutions, not features. All of the techniques of Kano analysis apply, the nuance of this approach is to refocus on problems (outside-in) not features (inside-out).

Use Kano analysis to identify each problem faced by



customers in your market as being in one of the following four classifications:

� Delighter – A solution to this problem will delight your customers. As markets change over time, customers lose their sense of delight, and come to expect solutions to previously solved problems.

� Must Be – This problem must be solved by your product, or your prospective customer will refuse to buy or recommend it.

� More Is Better – This is the classic shades of grey problem, in contrast to the black and white nature of a must be problem. Solving part of this problem is good, solving more of it is better. The easiest way to think of this problem is that solutions are partial solutions, and the greater the portion of this problem your product solves, the more satisfied your prospective customers will be with your product.

� Indifferent – This is a problem for which your customers are indifferent to the solution. Buyer decisions about purchasing your product (versus the competition) are not affected by how capably this problem is solved. Users will not judge your product’s effectiveness based on how well it solves this problem.

Conclusion / Request for Feedback

This view of the market as an organization of problems that are shared by groups of customers allows you to:

� Gain more insights from competitive analysis.

� Prioritize the content of each release to grow (revenue or profits or market share) faster.

� Design solutions that particular groups of customers will love.

Visit Scott Sehlhorst’s blog at http://tynerblain.com/blog/

http://tynerblain.com/blog/



The Importance of Software Requirements for Superior SoftwareDo you really need to pay attention to software requirements before you start coding? Read on to discover requirements lessons and best practices to help you ensure software success.

Have you ever been involved in a home or office building project? Did you end up with what you wanted? If so, it’s undoubtedly because you stayed involved and because, through the architect’s drawings, you had a way to communicate your requirements. The comparison of building a house to building a software system is one you’ve undoubtedly heard before. Nonetheless, the comparison is extremely useful, and it allows us to draw some crucial lessons.

Lesson one: You may have expressed your initial ideas in words, but the architect turned the words into drawings. Those drawings helped you ‘see’ what the finished product would be like.

Lesson two: The drawings you and the architect worked with were presented in your terms, not the electrician’s or the plumber’s. You could understand them.

Lesson three: You, the one paying the bills, had the opportunity to be involved and make changes throughout the life of the building effort.

Lesson four: The requirements, the original drawings that you and the architect worked through, drove the rest of the project. They produced electrical specs, plastering specs, and so forth. If the assumptions in those drawings changed, the changes rippled through.

Just as in building a house, a good requirements process must have a way to help the business owners extract, discover, and capture what they want in their own terms. A good software requirements process must have a way to communicate unambiguous requirements to the developers (the plumber, the electrician). And a good software requirements process must have a way to accommodate and even encourage change throughout the life of the project (you, the owner, are included in the process all along the way).

If your software requirements process doesn’t address these lessons, it won’t succeed.

The Importance of Software Requirements for Superior Software


Software Requirements Gathering Needs Both Words and Pictures

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

Software Requirements Must Be Gathered and Presented in Business Terms

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

Business Owners Must Be Responsible for Requirements throughout the Life Cycle

According to research done by the Standish Group the top reason for project failure is “lack of user input.” At least some of those project failures included JAD sessions to collect user information. They may have even had the users themselves write the requirements. Shouldn’t that have been enough? Apparently not. As one business user said, “We’ve written requirements documents, but developers can ignore written instructions as well as verbal. What we need is someone to make sure each requirement is implemented as written.”

Well, who should that someone be? I believe that it’s the business owner him/herself. But if your requirements are ‘thrown over the wall’ to development, that won’t be possible. Do you really want to abdicate that responsibility? If not, you need a way to keep your finger in the pie throughout the life cycle.

Requirements Are Central to the Entire System Life Cycle

How many legacy systems are out there with unknown business rules buried in the code? How many systems are we currently building without good documentation? Why can’t we find a way to ensure that business people not only specify the software requirements, but also have



a mechanism to understand what the system when it’s built will actually do? If you build good requirements models, they can lay the basis for the activities of many groups down the road, including user documentation, project manager, user acceptance testing, and the maintenance team.

A New Requirements Process

Question: “What most often dooms IT projects?”

Answer (from a Chief Technology Officer quoted in Software Magazine): “First, we don’t know how to talk about requirements in any precise way, which is a matter of the business people not understanding what we need – and IT doesn’t clarify this very well, either. Specifying requirements is a failure on both the part of the business and IT departments. Users have trouble expressing their needs and desires in a way that the technologist can understand. There must be someone in the middle to interpret what the user is saying and translate it to IT.”

Let’s return to the house analogy. When you embark on a building project it’s you, the owner, who has the vision of what you want and the money to pay for what it will cost. In all but the simplest cases, however, you turn to an architect for help. By using an architect you are getting the “someone in the middle” referred to above. That someone should have experience, should be able to model the solution in terms that you understand, and should be able to interpret and translate that to the technicians. Unless you, the business owner, have lots of time and lots of experience, you will need an outside “someone in the middle” for your application development projects.

Conclusion

Discovering, documenting and maintaining good requirements is the most crucial activity of the entire development life cycle. Don’t fall into the ‘why aren’t we coding yet’ trap, or allow your developers to convince you that they can build a good solution with little guidance from the business. Spending the time and the effort up front means a better solution in the long run.

This paper is an excerpt from a more extensive white paper. For more on this and other requirements topics, visit our web site at www.requirementsfirst.com

http://www.requirementsfirst.com

The Role of the Software Architect in Applications and Systems Development


The Role of the Software Architect in Applications and Systems DevelopmentHow do software architects shape your applications and systems development? Learn the insights from a seasoned project management expert.

In the early days of software development little thought was given to how the software applications and systems we built were architected. There were several reasons for this: firstly, software development being new, the concept hadn’t been thought of, and secondly we didn’t realize how important architecture was to the cost of maintaining our applications and systems. Upon sober reflection, we probably should have foreseen the need for planned

architecture and architects because building software isn’t radically different from building any other structure, for example buildings and bridges. We can’t go back and undo the damage done by the lack of foresight that led to badly architected applications and systems but as project managers we can avoid making this mistake in our next software development project.

Today most organizations whose core competencies include software development recognize the importance of architecture to their business and have satisfied this need by creating the role of architect and making this person responsible for the architecture of all the software applications and systems they develop. Even organizations whose core competencies don’t include software development, but who have invested heavily in IT, have created this role. These people may be referred to as the Chief Architect, Head Architect, or Strategic Architect. Wikipedia identifies 3 different categories of architect depending on the scope of their responsibilities: the enterprise architect who is responsible for all an organization’s applications and systems, the solution architect who is responsible for the architecture of a system comprised of one or more applications and hardware platforms, and the application architect whose responsibility is limited to one application. The category and number of architects will usually be constrained by the size of the organization and the number of applications and systems it supports. Regardless of what the organization you work for calls them, the software architect has a key role to play on your software project.

Your job as project manager of a software development project, where a software architect is in place, is to ensure that their work is properly defined and organized so that your project receives maximum benefit from their expertise. If the organization does not have an architect in place you will have to identify someone on your team to fill that role. What is not acceptable



is to plan the project without any acknowledgment of the need or importance of the architect. This role requires as much knowledge of the system components as possible, including software and hardware knowledge. It also requires deep technical knowledge of the technology being used, both hardware and software and strong analytical skills. The person (other than a software architect) who most probably possesses a skill set similar to this one, is a business or systems analyst. Depending upon the size and complexity of the existing system, and your project, existing skill sets may not be sufficient to meet your project’s needs. There are ample training opportunities available so pick one that most closely suits your needs and have your candidate attend. If your project has adequate budget to pay for the training, fine. If not, keep in mind that the skill set acquired by the trainee will be available to the organization after your project is completed and your project should not have to bear the full cost of the training.

Now that you have a qualified software architect engaged for your project, you need to plan that person’s tasks to take maximum advantage of their skills. I recommend engaging the architect as early on in the project as possible so that they can influence the definition of the application or system being developed. The team that defines the business requirements to your project will be from the business side of the organization and have deep knowledge of how the business runs but little knowledge of the existing systems and technical features of the hardware and software that will deliver the solution. Having a software architect available during requirements gathering exercises will help you define requirements that leverage existing system and solution platform strengths and avoid weaknesses. Leaving their input till a later phase exposes your project to the risk of re-engineering the solution to fit existing architecture or avoid solution weaknesses, after the fact. Involve the software architect in requirements gathering exercises as a consultant or SME (subject matter expert) who can point out risks in defining requirements and offer alternative solutions. The key deliverable your architect is responsible for is the architectural drawing. This is not actually a drawing but a mix of drawings and text. The drawings will represent the various components of the system and their relationship to one another. The text will describe data elements, relations between various architectural elements, and any standards designers must adhere to. The drawing may be a new one to represent a new system, or it may be an update of an existing drawing to reflect the changes to an existing system made by your project. The development of the architectural drawing is the first design activity in your project schedule. The drawing is used in the same fashion that engineering staff and skilled craftsmen use an architectural drawing of a building or bridge.

Analysts and programmers will use the Business Requirements Document (BRD) to tell them what features and functions to design and the architectural drawing to tell them how their software must fit together with other software in the system, any constraints the system places on their design, standards the new software must meet, and what critical data elements look like. The information in this drawing will depend on the solution chosen, the hardware chosen, the existing system and the complexity of the project. For example, projects using an Object Oriented solution will have 4 layers: a user interface layer (the layer the user sees), an

The Role of the Software Architect in Applications and Systems Development


application layer (where the work is done), a domain layer (where business logic is applied), and an infrastructure layer (for logging messaging, etc.). Other solutions may call for more or fewer layers. Software development projects which rely on a relational database to store and retrieve large volumes of data will have a database architect who is responsible for the design of the database. The database architect should be a member of your project team and their design should be coordinated with the system architecture so that the data elements in the architectural drawing are defined the same way as they are in the database’s data dictionary. Database design is critical to system performance. Poor database design, or database design which does not support the applications using it, will deliver a system with poor performance so database design and architectural design must be inputs to one another to yield a well integrated system with the performance characteristics required.

The architectural drawing must be approved by the project sponsor, project steering committee and the organization’s enterprise architect/chief architect/head architect where that person is not the architect on your team. In many cases people other than another architect will not have the ability to determine whether the drawing contains all the information required by the project, or whether the system design is sound. They will be able to determine that each category of information has been addressed and that the drawing meets any requirements defined for it in the Project Charter, Statement of Work (SOW), or scope statement. Once the drawing has been approved it should be communicated to the analysts who are responsible for producing design specifications.

The software architects role does not end with the production of the architectural drawing, indeed in some software development lifecycle (SDLC) methodologies this drawing will be produced iteratively. It may be produced in stages such as the infrastructure layer first, the domain layer next, etc. or it may be produced iteratively, one new version for each iteration. Even projects using Waterfall SDLC methodology won’t necessarily produce a final drawing during the project planning phase because they don’t need to. The designers need to have a drawing that provides them with the information they need when they need it and you may need to begin design work with the drawing you have in order to keep to schedule.

The architect must also ensure that the design captured in Functional specifications and detail design documents conforms to the constraints placed upon it by the architectural drawing. To do this they must review the designs to determine compliance. The architect should be a member of any peer review teams reviewing design. This may not be possible, especially if you have to share an architect with another project or operations so at minimum the architect should review each design and ensure compliance with their architectural design, or identify gaps where it does not.

The hardware and operating systems which are components of the system architecture are areas of oversight for the architect. Projects which call for procurement of these items, or outsourcing of the development of any applications, should engage the architect to contribute to product and vendor selection criteria. Some architectural drawings may specify hardware and software



depending on the solution being implemented, in which case the information should be included in the architectural drawing. Where requirements for these things are less well defined, the architect should make certain that selection criteria properly reflect their architectural requirements and that the statement of work for any outsourced software is correctly written. In projects where software development work is outsourced, the architect’s role will be the same as if the work were being done in-house. Large projects which require the vendor to staff their team with a software architect should have their architectural design overseen by the architect for your project.

Finally, the architect should also be called upon to analyze any changes to software design or functionality that could cause a change in the architecture. Your architect will be the right person to analyze any request to determine where a change in the design of one system component would impact on other components of the architecture. Once the architect has determined if a change in other components would be required, and what the nature of that change would be, it’s up to your design and build gurus to assess the cost of that change.

About the Author

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

http://www.threeo.ca/

The High Costs of Building the Wrong Product


The High Costs of Building the Wrong ProductCosts explode when you start building the wrong product at the early requirements stage. Learn how you can avoid it.

As product managers, we often talk about creating the right solutions with our products. Understanding the very real problems that our customers face, understanding the very real opportunities our markets present, and manifesting that understanding in a product roadmap.

Other than being “not as good,” how expensive is it to build the wrong product?

The Cost of Poor Quality

There’s an analog to the market dynamics of making poor product decisions – executing with poor quality. Many research studies and articles have identified the market impacts of poor quality. This has become so well accepted that people today cite it like a law of physics as the “1-10-100 rule.” The primary conclusion of that research is that ten dollars spent on fixing bugs:

� Costs and saves $10 when you catch (and fix) the bug during implementation.

� Avoids $100 in costs when you catch the bug during QA and send the product back to development (then test again).

� Avoids $1,000 in costs versus waiting until your customers catch the bug in the field, causing the team to remedy the problems, rush out a patch release, and/or go to heroic lengths to manage a PR problem.

This is an opportunity in front of your product team – a 100x payback from investing in quality during the development process. Of course, be pragmatic about it - if the cost of testing exceeds the cost of bugs, don’t test.

This is not a solved problem, by any stretch, but the solutions and methods to solve this problem are well understood now. In fact, a 2001 article by Barry Boehm and Victor Basili shows that in some cases, the labor costs to resolve bugs can be as low as 5:1 – when considering a subset of smaller systems, when using more “agile” processes. That lowered ratio does not take into account the lost market opportunities and the costs of cleaning up collateral damage to your product – just the immediately realizable (and measurable) costs of resolution.

One very real problem, when talking about “bugs” is in defining what a “bug” is. And the definition

http://www.cs.umd.edu/projects/SoftEng/ESEG/papers/82.78.pdf



of a bug is a matter of perspective. A developer can reasonably assert that “if it meets the spec it is not a bug, it is working as designed.” What if the spec is wrong? The developer may not be guilty, but collectively, your team screwed up. There’s a “bug” in the requirements.

What Is a Requirements Bug?

Now things are getting interesting.

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

� Make sure you have a shared understanding of the documented requirements through active listening before development begins ($1). Following the Rules of Writing Requirements will help prevent this miscommunication.

� Wait until the engineering team is ready to demo their progress ($10). They will have to build it again, because they built the wrong stuff.

� Wait until development is complete and QA is validating that the code meets the spec ($100). This gets tricky if you are thinking “A”, the developers are thinking “B”, and QA is thinking “C.”

� In classic throw-it-over-the-wall mode, wait until the product is launched, and it is the wrong product ($1000). Assuming “A” was the right problem to solve, the cost of entering the market with a solution to “B”, leaving “A” unaddressed, is impressively high.

This gets interesting because the above assumes that “A” was the right problem to solve. What if “G” was the right problem to solve, and “A” was the wrong market problem? Even if everything (else) is working perfectly – you document requirements for “A”, the engineering team creates a marvelous “A” and it launches without implementation errors – you still fail, and incur the 1,000x cost of a failed product launch.

There is an even larger opportunity in front of your product team – a 1,000x payback on discovering and choosing to solve the right problems for your customers and markets.

� Would Palm still be independent if the Pre had solved a compelling problem?

� Why did Intuit have to buy Mint.com – could they have embraced the same customers with Quicken?

The High Costs of Building the Wrong Product


� What is Garmin going to do now that “free” GPS mapping and turn-by-turn directions are becoming ubiquitous? If it is “more of the same,” how much are they wasting?

Wrapping Up

I’m not aware of any studies that show that “requirements bugs” fit the same 1/10/100/1000 cost explosion model that “implementation bugs” exhibit. Emotionally, it “feels about right” to me – it passes my “sniff test.”

There are times when days of research would have been required to avoid or redirect a few hours of implementation effort on projects I’ve worked on. And I’ve seen man-years invested solving problems that didn’t involve much more research.

My intuition from products and teams I’ve worked with is that it probably averages out somewhere around 10x.

Visit Scott Sehlhorst’s blog at http://tynerblain.com/blog/

http://tynerblain.com/blog/



Business Process Improvement is a Strategic NecessityLong-term competitive advantages require continuous business process improvement

Business Process Improvement Overview

Business process improvement initiatives are frequently key projects within an organization – regardless of the size of the organization or, frankly, the size of the business process improvement initiative. Even if a business process improvement initiative is targeted at an individual department, the impact of the change will be organization-wide. By ensuring that the initiative is managed as a strategic project, there

are increased opportunities for success.

Process improvement initiatives are continuous. As organizations grow, they need to continuously analyze and refine their processes to ensure they are doing business as effectively and efficiently as possible. Fine-tuning processes gives an organization a competitive advantage in a global marketplace.

Process improvement is a strategy and a tool to help an organization meet its long term goals and objectives. One key goal for all organizations is to meet the demands of their clients – both internal and external. Clients’ needs change – whether due to economic factors, new product introductions, mergers or acquisitions, expansion or contraction. Continuously reviewing processes for potential improvements and efficiencies enables companies to adapt effectively to their clients’ changing needs.

Sometimes improving one process may inadvertently have an adverse affect on other processes. For example, let’s say a company changes its sales order processing. Once that process is improved, it becomes apparent that the improvement in that process has created a backlog in order fulfillment in the manufacturing department. A project management approach would address such issues as part of the risk planning, and the order fulfillment process would have been reviewed as an extension of the sales order process. Or, the initial project would have been assessed to determine if making changes to the sales order process would be beneficial to the company as a whole, given investments needed for other parts of the company.

Business Process Improvement is a Strategic Necessity


The following graphic depicts a lifecycle of a process improvement initiative:

Although a project has a defined beginning and a defined end, in this graphic we are depicting a cyclical environment for continuous improvement. While this may be confused for ongoing operations after deployment of the initial process improvement project, it should, rather, be looked at as a separate project for each cycle of improvement. While monitoring is operational, once a need for improvement is recognized; a project with a defined beginning and a defined end and with set goals and objectives is established.

When process improvement initiatives are formally undertaken, by a project team led by an experienced project manager (experienced in process improvement-type projects), the following high-level overview steps will likely comprise the project work:

� Documenting the current process to be analyzed.

� Measuring the current process (gathering metrics) and developing a baseline. Metrics may be customer-based or organizational-based.

� Customer-based metrics may include:

� Customer satisfaction

� Service level

� Time to market

� Accuracy of customer orders

� Organizational-based metrics may include:



� Utilization of resources

� Manufacturing line utilization

� Cost per unit for development

� Validating the documented current process and ensuring metrics are baselined appropriately.

� Setting new metrics for the process based on organizational long-term goals – e.g., one improvement may be to go from 85% customer satisfaction to 93% customer satisfaction over a 9 month time period or to reduce cost per unit from $25 per unit to $15 per unit over a one year time period.

� Analyzing the process as documented to make improvements.

� Design and develop changes to the process to ensure improvements as desired.

� This, along with documenting a process, can be the most significant amount of time on the project.

� Validate the design to the process.

� Implement the new process change.

� Review and measure the results of the new process change.

� Measure against baseline metrics in a designated time period.

Overview of a Case Study: Process Changes for a Manufacturing Company

This paper will provide a high level overview of a case study of a manufacturing company that saw the value in taking a project management approach to a process change initiative.

Overview

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



The Project Plan

ABC Projects outlined a project plan with tentative timelines and cost ranges until discovery was completed. The project plan included the discovery and identification of needs for increased production, as well as identification of affected departments and/or processes if the increase in production were carried out.

ABC Projects knew from experience that other areas besides the manufacturing line would be affected. For example, procurement had a set budget for purchases. The expenditure necessary for materials that were not ready to be used in manufacturing would wreck havoc on cash flow and require consideration of how to store materials until they are ready to be used by manufacturing. Further, additional vendors from which to purchase the materials would need to be identified, should the current vendors be unable to meet procurement’s increased demands. Alternative vendors needed to be in place before any supply issues arose. It was evident that the processes for procurement must be very closely integrated with the manufacturing processes to maintain an ongoing flow of materials to production.

The project team developed a detailed plan for identifying the stakeholders and how they would proceed to gather the data necessary to accurately document the manufacturing processes. The plan included a detailed list of questions to ask each stakeholder to ensure that all interviewers asked the same questions and gathered the same data. The project team knew from experience that documenting processes required a thorough understanding of the business, because, when being interviewed, individuals often unintentionally skipped relevant details. Thus, experienced people were required to extract information needed for an accurate and detailed documentation of processes.

The project team also developed a plan for potential risks and strategies for managing them should they come to fruition. They wanted to be sure that once they determined the options for making changes to the manufacturing processes, that they could accommodate potential changes to other processes. They knew that changing one process would likely have a domino effect throughout the company. For example, during one of the scenario planning sessions, the project team found that if procurement was unable to fulfill the material needs of manufacturing from one vendor, without a back up vendor in place, there would potentially be a shortage of materials which would cause a delay in production or costs would increase by at least 30%. This would be unacceptable and would ultimately cause customer dissatisfaction which could lead to a loss of business to competitors.

The team also put together a change management plan; because a major component of the project would be communicating changes company-wide and ensuring the appropriate people were on-board and prepared to work with the new processes. Additionally, the project team needed the individuals involved on the production line to be willing to test new processes as well as new equipment with no interruption in meeting current client demand. Without support



from these individuals, this would be an impossible task and one that had a high potential of risk associated with it.

Additionally, the project team sent out a company-wide communication so that employees knew what was happening and why, and they asked for suggestions from employees. By getting the input of the individuals who were doing the job day in and day out, they increased the likelihood of success on the project.

The Work Breakdown Structure included several milestones to allow the company to move forward with working with new processes and upgrades to equipment without interrupting the current production schedule. At each milestone, there were several tasks for measuring progress and comparing it to expected results and baselines. Assessments were completed regularly to ensure the current plan held true to the objectives. At any point during the project, if the assessments showed deficiencies from the objectives, then an evaluation of the process design and, if necessary, a correction occurred. The Work Breakdown Structure included training time to get individuals up to speed on new equipment.

The Risk Management Plan included contingencies should current employees be incapable of learning the new equipment and performing their role in a timely fashion. Part of the contingency plan was to use employees who adapted quickly to the new equipment on the new production line and maintain the old production line with employees who learned less quickly, until they were able to get up to speed. An integrated team concept, including mentoring, was put in place to assist people in getting up to speed on new equipment.

Regular status meetings were scheduled with manufacturing, procurement, delivery and other departments to maintain lines of communication and general awareness of the project status. These meetings also served to ensure that employees were comfortable with change and were able to participate in decisions that would affect how they perform their job.

Project Results

Prior to undertaking the project, Company XYZ was producing 250 widgets per day. At the time of the undertaking of the process improvement initiative, client demand had just reached 250, and demand had increased by 10% annually over the last five years and it appeared that the increase would continue for the foreseeable future.

The directive from the executives was to improve manufacturing processes through changes in processes as well as upgrading equipment, toward a goal of producing up to 400 widgets per day. Based on current projections, the company would experience a five year timeline before having to undertake another increase in production to satisfy growing client demand. At that point, if client demand continued to increase, the company would be in a better position to invest in another manufacturing site in order to meet demands after the five year mark.



Additionally, in the current production line there was, on average, a 3.6% defect rate in widgets produced. One of the directives specific to this project was to attempt to reduce this defect rate by at least half within the next two years.

The following were discovered during the project:

� Capacity for procurement was limited due to cash flow and budgetary issues, as well as storage. Any new process needed to take this into consideration once production increased and would have to allow for a smooth flow between procurement and manufacturing.

� It became apparent that once the number of widgets manufactured increased, demands on warehousing and delivery would increase accordingly. A plan was put in place to change warehousing and delivery processes to reduce the strain on these functions.

The project had run slightly over the projected timeline, but did remain within budget. The increase in the timeline resulted from an underestimate of the space required to store manufactured widgets prior to delivery. This occurred to a great extent because the decrease in the defect rate was .06%, significantly exceeding the goal of 1.8%, thus causing an increase in the number of widget units to be stored. Although this was not anticipated in a contingency plan it did not cause the executives to be unhappy. It was a good problem.

Summary

A project management approach enabled the company to meet their production needs for the future, while at the same time not disrupting their current production to fulfill client demand. There was never a glitch in the production line while new processes were being tested and evaluated. Continuous communication ensured that everyone was in the loop on changes to processes and actually had the benefit of increasing participation from employees on how to improve processes to better meet client needs. Additionally, continuous review and adjustments to the risk management plan ensured that the end result was well thought out and tested and ensured that any glitches in proposed changes were caught immediately and could be addressed.

Adhering to a standard project management methodology enabled this company to implement a very high risk project efficiently, on budget and within reasonable time to meet long term strategic goals.

Copyright ©2009 – 2010 Gina Abudi. All Rights Reserved Worldwide. http://www.GinaAbudi.com http://www.PeakPerformanceGroup.com

About the Author

Gina Abudi is Partner/VP of Strategic Solutions at Peak Performance Group, Inc.

http://www.GinaAbudi.com

http://www.PeakPerformanceGroup.com



She has worked with clients on a variety of strategic initiatives, including conducting Business Impact and ROI studies for training programs and process improvement initiatives, project management, developing strategic learning and development programs, assessing skills, and developing mentoring programs.

Gina was honored as one of the Power 50 from PMI® - one of the 50 most influential executives in project management, working to move the profession forward.

Gina has served on PMI®’s Global Corporate Council as Chair of the Leadership Team and serves on the PM Summit/BA World Advisory Board. She was previously an Associate Board Member for Simmons School of Management Alumnae Association.

Gina has presented at conferences on business impact and ROI, developing project management best practices, building effective teams, and assessing project management skills. Gina received her MBA from Simmons Graduate School of Management.



SOFTWARE-as-a-SERVICE

Software-as-a-Service


Cloud Computing Reality CheckA tempered examination of cloud computing’s advantages and disadvantages

There is a noise going about that cloud computing can cut costs, speed implementations, and scale quickly. However, the noise may be slightly off-the mark – particularly in product pitches!

What is Cloud Computing

Search.com provides the following definition of Cloud Computing:

“ Cloud computing is a general term for anything that involves delivering hosted services over the Internet. These services are broadly divided into three categories: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS). “Cloud computing is a general term for anything that involves delivering hosted services over the Internet. These services are broadly divided into three categories: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS).

The term cloud is used as a metaphor for the Internet, based on the cloud drawing used to depict the Internet in computer network diagrams as an abstraction of the underlying infrastructure it represents. Martin Banks, Associate Analyst at Bloor Research for Data Centres, told me, “I prefer the term Exostructure – an externally sourced (and theoretically limitless) seamless extension of an internal IT systems infrastructure that delivers information services on a fee-paying basis. This is looking at the issue from the users’ point of view.”

Cloud Computing Service Categories

Infrastructure-as-a-Service

Infrastructure-as-a-Service, like Amazon Web Services, provides virtual server instances with unique IP addresses and blocks of storage on demand. Customers use the provider’s application program interface to start, stop, access and configure their virtual servers and storage.

Platform-as-a-Service

Platform-as-a-Service in the cloud is defined as a set of software and product development tools

Cloud Computing Reality Check


hosted on the provider’s infrastructure. Developers create applications on the provider’s platform over the Internet. PaaS providers may use APIs, website portals or gateway software installed on the customer’s computer. Force.com, (an outgrowth of Salesforce.com) and GoogleApps are examples of PaaS. Developers need to know that currently, there are not standards for interoperability or data portability in the cloud.


In the Software-as-a-Service cloud model, the vendor supplies the hardware infrastructure, the software product and interacts with the user through a front-end portal. SaaS is a very broad market. Services can be anything from Web-based email to inventory control and database processing. Because the service provider hosts both the application and the data, the end user is free to use the service from anywhere.

A cloud service has three distinct characteristics that differentiate it from traditional hosting.

� It is sold on demand, typically by the minute or the hour;

� A user can have as much or as little of a service as they want at any given time; and

� The service is fully managed by the provider (the consumer needs nothing but a personal computer and Internet access).

What Cloud Computing Means to Business

Well, rather than running computer applications on an in-house computer, you run them on an external machine, which could be anywhere in the world, and access the application programs via the internet. It also means that the data associated with the application is held externally to your organisation. So the application is hosted on a server with the associated data being stored in a database – all on a server run by a third party.

There is just one more piece that we need to understand and that is that a cloud service can be either public or private. What does this mean? A public cloud sells services to anyone on the Internet. Amazon Web Services is the largest public cloud provider at the time of writing. A private cloud is a proprietary network or a data centre that supplies hosted services to a limited number of people. Just one more term that you need to understand and that is virtual private cloud; this is when a service provider uses public cloud resources to create their private cloud.

What makes cloud computing so appealing at the moment? In a recent article [1], Nigel Stanley, Bloor Research’s Security Practice Leader, said the following, “In an economic downturn cloud computing oozes sexiness. The thoughts of off loading your data to a third party gets financial types excited as they start to see how much money can be saved.” Cloud computing means that rather than purchasing software, which would go on your CAPEX, you pay for it when you use it so it comes off your OPEX budget instead. Banks feels that, in fact, cloud computing will also



reduce your OPEX spend as well as the implementation costs and associated consultancy costs will be less as well. On one point that Banks made I am not sure that I would agree with in that he felt the integration cost would also be smaller; I am not so sure and would advocate budgeting the same as an in-house implementation.

How Can Cloud Computing Be Used in Manufacturing

CRM has been one of the first areas covered; this being piloted by salesforce.com with its launch in 2000. Salesforce.com’s CRM solution is broken down into several modules: Sales, Service & Support, Partner Relationship Management, Marketing, Content, Ideas and Analytics. Salesforce.com’s Platform-as-a-Service product (Force.com Platform) allows external developers to create add-on applications that integrate into the main Salesforce application and are hosted on Salesforce.com’s infrastructure. Salesforce.com currently has 55,400 customers and over 1,500,000 subscribers. Why CRM? Well the answer, in my view, is due to the need to support a mobile sales force that needs to be able to record information easily and quickly without necessarily having contact always to the centre. Couple this with the need for the centre to have control over this distributed workforce and you create an ideal environment for cloud computing solution.

A number of the large ERP vendors, such as SAP, provide cloud capabilities. SAP launched its Business ByDesign in September 2007. Over the past couple of years Business ByDesign has been plagued by some really bad press. In September 2009, SAP gave a briefing to the industry on how it was tackling a number of the issues. These included:

� Scalability issues: all customers run on their own blade servers

� Overly “feature-rich”: the suite was originally designed to meet all of the needs of its customer base instead of focusing on specific functionality

� Lack of corporate commitment: SAP is cutting R&D funding and shifting resources to other products

� Runs on NetWeaver: a full instance is too heavy for a SaaS application and finding “cloud developers” who have full Java EE stack experience may be tough

Infor entered the market in October 2008 with the launch of a SaaS version of ERP SyteLine. This is a very typical entry from an existing vendor in that it allows a user to move seamlessly between SaaS and on-premises deployment, or vice-versa.

Microsoft Dynamics entered the SaaS market in 2007 with the introduction CRM Live. This is run at Microsoft data centres around the world, along with all the other “Live” products such as Live Small Business Office. Software-plus-Services for Microsoft Dynamics ERP is the new capability being offered. This allows a user to choose to implement their Microsoft Dynamics software as a wholly-owned on-site solution, via online services, all or partly- hosted, or in any combination.

Oracle entered the market last year with the introduction of an offering comprising its Oracle



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

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

Where Else Cloud Computing Can Be Used

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

Cross enterprise collaboration

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

High Performance Computing

Verstraete foresees the needs for additional computing power, as companies increase the use of digital models to virtually test their products and/or to understand their business environment better through business intelligence and decision making. The models used are typically highly parallelizable and fit well for a cloud environment as long as the amount of data they need to be provided with is not large, when the network could become a bottleneck.



But cloud computing can get a business in hot water if they have not thought through the many consequences, and this particularly means data security. Stanley states, “Without assurances that organisational data will be totally secure in a remote site the whole concept of cloud computing is dead in the water.” So securing the cloud is vital for its success. With companies trusting their corporate data – their most important asset – to third party organisations, what another of my Bloor colleagues, Peter Cooke, describes as the holy trinity of confidentiality, integrity and accessibility, has to be assured. The infrastructure underpinning this is Identity Access Management (IAM). Without it, system access security is non-existent.

Another worry is about the ability of the provider of the service ability to still be around tomorrow. Raimund Genes, CTO at Trend Micro, the global security company, in a recent eBook[3]. “You need a provider that will be in business three years from now. When you give up your IT infrastructure, you need a reliable service provider.” Banks stated that “With Cloud Computing you must realize that your business process in no longer in your complete control. It is wrapped into the cloud service and in the control of the provider” Therefore it is imperative that when choosing a cloud service provider, you choose one that is likely to be there for the long-haul, or a supplier that has a strategy to manage the situation if they are not there. Could we ESCROW agreement for business processes locked in cloud services?

The goal of cloud computing is to provide easy, scalable access to computing resources and IT services. Cloud computing users gain some significant economic advantages. They have no capital expenses. They have reduced service costs because of a simplified IT infrastructure. They do not have to buy systems scaled to their worst case use scenarios, and there is a reduction in large client applications. The primary disadvantages are the risks associated with Internet reliability, security and access of data, and the financial stability of the service provider.

References

1. Generating Maximum Value from your IT Security Spend - An Analyst’s Perspective. Nigel Stanley, Bloor Research, 29 September, 2009.

2. The Cloud Computing Advantage for Companies that Outsource Manufacturing, Dr. Katherine Jones, Industry Week, April 24, 2009

3. What to Expect from Cloud Computing, internet.com, Three Steps to Secure Cloud Computing, Robert McGarvey, 2009

About the Author

Simon Holloway is the Practice Leader. Process Management & RFID at Bloor Research.

His background spans some 20 years as an IT consultant specialising in IS/IT strategy planning, information management, corporate data and process modelling, business process

http://www.bloorresearch.com/



reengineering, software selection and project management.

Simon has several areas of specialism from his wide-ranging manufacturing, BPM and RFID experience. For example, he is well versed in the concept of agile manufacturing and the use of web services in the sector. He is also knowledgeable in the use of virtualisation within supply chains.



Are On-Demand Applications Right for Your Business?What you need to know about IaaS, PaaS, SaaS and the emerging on-demand applications market

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

Essentially there are three levels of on-demand offerings. These mirror the way IT is increasingly deployed internally.

The lowest level is infrastructure-as-a-service (IaaS). This is where pre-configured hardware is provided via a virtualised interface or hypervisor. There is no high level infrastructure software provided such as an operating system, this must be provided by the buyer embedded with their own virtual applications.

IaaS is particularly useful for organisations that are running virtualised applications internally, but may want to make use of additional capacity when their own resources are stretched. On demand storage is applications are also considered as IaaS.

Platform as a service (PaaS) goes a stage further and includes the operating environment, including the operating system and application services. PaaS suits organisations that are committed to a given development environment for a given application but like the idea of someone else maintaining the deployment platform for them.

SaaS goes the whole hog, offering fully functional applications on-demand applications to provide specific services such as email management, CRM, ERP, web conferencing and an increasingly wide range of other applications.

Many independent software vendors (ISVs) are now turning the SaaS model and making on-demand applications as versions of their applications available. To do so they are often using IaaS or PaaS for deployment.

Much of the coverage of on-demand offerings focuses on a few high profile vendors and it is easy to think the market is restricted to them. This is simply not true; many managed hosting

Are On-Demand Applications Right for Your Business?


providers are now providing IaaS and/or PaaS as an alternative to their traditional dedicated infrastructure hosting services. Add to this the number of ISVs now offering full or partial SaaS and the aggregated market these organisations represent is easily as big as that of their higher profile counterparts.

Choosing a supplier will depend on the type of platform required, the SLA on offer and the guarantees that can be offered around security and governance.

Perhaps the most high profile IaaS platform is the Amazon Elastic Compute Cloud (EC2). Other examples are Attenda’s RTI and Rackspace’s Cloud Servers (currently in beta and being fully launched in the next few months).

PaaS platforms included Microsoft’s Azure, which is based on Windows and .NET (needless to say) and Google’s AppEngine (Java based). Some PaaS offerings have a particular focus; force.com (the original salesforce.com platform) only supports applications developed using its proprietary APEX language. It was mainly aimed at customers wanting to extend their salesforce.com CRM deployments and ISVs wanting to sell their applications to existing salesforce.com customers. The new VMforce offering allows them to do that with Java as well. Rackspace’s Cloud Sites is used primarily for web sites, although some use it for applications.

SaaS includes a wide range of offerings including enterprise applications such as CRM and ERP, utility services including email, web conferencing and content security. The range of vendors is huge.

So why all the fuss—what is actually in it for you, the buyer? Just focus on the cost of the platform and all does not seem to add up. If you go out and buy your own hardware and software after 8 quarters it is quite possible that the cumulative spending on an on-demand subscription could outstrip that of an on-premise deployment. But this only looks at hardware and software costs. The point is that by using an on-demand supplier you are also buying access to highly secure enterprise data centre facilities, skilled staff specifically trained to support given applications and infrastructure, regularly scheduled backups, built in redundancy, easily shareable applications for supporting cross organizational business processes—to mention just some of the benefits.

Add all this in and, for many, the cost is easily outweighed by the reduced risk and added value of on-demand services. And don’t forget, at some point all that on-premise hardware and software will need replacing; with on-demand providers that is part of the service, or at least it should be.

For many SMBs the business continuity option offered by on-demand services should be irresistible. For many enterprises, running utility IT applications via on-demand services also makes sense, freeing IT departments to focus on the applications that deliver unique value to their businesses.



Conclusions

� There are many more players in the on-demand market that many reports acknowledge

� These range from basic infrastructure offerings (IaaS), through platform support (PaaS) to full applications (SaaS)

� The long term cost of ownership may at first not seem to add up, but take into consideration other factors such as reduced risk and added value and for many organisations on-demand services make a lot of sense

About the Author

Bob Tarzey is a Service Director at Quocirca Ltd. His main area of coverage is route to market for ITC vendors to enterprises, the mid-market and small businesses (SMB). He leads many of Quocirca’s projects for IT vendors and channel organisations.

Bob has extensive working experience of channel management. Prior to joining Quocirca in 2002 Bob spent 16 years managing channels for US technology vendors including DEC (now part of HP), Sybase, Gupta, Merant (now Serena), eGain and webMethods.

Bob writes regular analytical columns for Computer Reseller News, The Register and silicon.com.

Bob has a BSc in Geology from Manchester University and PhD in Geochemistry from Leicester University. Bob completed his PhD on time and on budget, within 3 years before the money ran out - not a common achievement.

http://www.quocirca.com/

Six Things for CIOs to Consider Before Moving to Cloud Computing


Six Things for CIOs to Consider Before Moving to Cloud ComputingCloud computing may have been hyped but it can offer real benefits provided you address certain issues up front. Don’t board the cloud computing bandwagon before addressing these issues.

Cloud computing has been hailed as the cure for all IT ills. Fortunately, a measure of reality is now returning to people’s view of the technology and the business value cloud computing can provide.

Nevertheless, some organisations are still not thinking through the issues of cloud computing, which may cause them problems down the line. If these issues aren’t accommodated for, the cloud can become a barrel over which providers can stretch client organisations. So, what are those issues and how can we minimise their impact?

Cloud Computing Issues

1. Data ownership

The first issue is making sure you own the data and that this ownership is built into the agreement with the provider.

The application, the hardware, the operating system and everything else can be owned by the cloud provider. But the data is what your intellectual property is predicated upon and it has to be acknowledged that you can take that data away with you as you see fit.

2. Data access

Data ownership does not amount to much if you are denied access to that data to migrate it away from the cloud computing provider.

Your cloud subscription gives you access to the functionality of the application or function that you use. If that access is removed, can you still access the data so that you can take it away with you?



Make sure the contract allows for access to the back-end data, either directly or via the provider offering an export capability, even after the contract has finished.

3. Data volumes

Cloud is great for off-site elastic computing, where extra resources can be applied in the form of more compute power, or more storage. However, as that storage capability grows, so does a specific problem.

Migrating 1GB of data across a wide-area network is pretty simple but how about 1TB? That migration can take a long time, and if you need to work against that data in real-time, you’ll have to plan for a degree of downtime while the data is pulled from the cloud and reinstalled against a replacement application or function.

Even if you can agree to set up a mirrored cloud or on-premise data topology, look out for clauses in the agreement that charge for data volumes.

Also, look at data cleansing and deduplication options, which can minimise overall volumes. If left unmanaged, mirroring data can rapidly become a major cost if data transfers are being charged for.

4. Data usability

Most cloud-based systems are built on a standardised database but that does not mean you can, for example, take a copy of the database from Salesforce.com and use it on a NetSuite system.

For an on-premise system, you have to understand the database architecture. For a cloud-based system, that understanding is just as important. Data has to be...massaged to be usable by the receiving system. It is best to plan for this possibility early, rather than waiting to see if or when it may be required.

5. Competitive acquisition

Why should a bank or a retail organisation not become a cloud provider? If they have datacentres that they suddenly realise can be highly virtualised, they could find themselves with spare space usable for little else apart from housing datacentre equipment.

These circumstances are essentially how Amazon started in cloud computing. If you are a bank using a cloud-based service and your provider is suddenly taken over by one of your competitors, would you be happy to allow them to run your email system for you? Probably not. You need to plan how to migrate rapidly to an alternative.

6. The nuclear option

Six Things for CIOs to Consider Before Moving to Cloud Computing


What do you do when the chosen cloud supplier goes out of business? There has been continual churn in hosting providers and the application service provider model of the 1990s showed how a few high-profile failures can start a stampede.

Granted, today’s providers come from a more stable stock, and the business models should provide greater longevity, but a degree of churn is inevitable.

If a provider goes bust, then an administrator is likely to be appointed to try and sort out the business. Some administrators will try and sell it as a going concern, in which case there should be fewer problems than if a predatory administrator is put in place.

But many administration companies seem to be moving more rapidly to asset-stripping. They identify the assets, sell them off, pay anything that is owed to the biggest preferential creditors - usually the government - pay their own bills and then see if there is anything left.

This approach brings its own problems, the first of which is gaining access to your data. You can deal with this situation by implementing suitable data topologies with full-image or incremental and snapshot capabilities to a backup storage facility. The real problem is how the administrator disposes of equipment.

You won’t have to bother about the application servers, because there’s no intellectual property in there. But storage systems? If these are just being packed up and resold, then copies of your data could well be sold on in a usable format.

It is imperative that the contract includes data encryption at rest so data is more difficult for people to do anything with on storage recycling.

It should also be part of the contract that storage units are cleansed of data at a forensic level before being disposed of, no matter who owns the cloud company or data facility at the time of disposal.

The cloud has many benefits and will form an increasing part of an organisation’s IT platform. But to get the most from it, forethought and planning is required. Dealing with data so that it doesn’t become a major issue should be a priority for those deploying cloud services.

About Quocirca

Quocirca is a user-facing analyst house known for its focus on the big picture. Made up of experts in technology and its business implications, the Quocirca team includes Clive Longbottom, Bob Tarzey, Rob Bamforth and Louella Fernandes.

http://www.quocirca.com/



Will Project Managers Have Their Heads in the Cloud?Cloud-based applications and Internet-based systems are rapidly gaining popularity. Read on to find out some clear advantages of the cloud for enterprise project management and a few things to be aware of.

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

What Microsoft has been betting on is moving many of its products to the “Cloud” where users can consume them online. As I was talking about this new message of Microsoft’s to my wife it prompted the obvious question, “What is

the cloud?” I had to think about it a minute. What does the IT industry mean when we talk about Cloud Computing and what are the implications to the project management software industry and to project managers in general? First of all, like almost anything in the IT world, there are numerous meanings; the cloud designation comes from network diagrams which had to depict connections to something out in the Internet.

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

Will Project Managers Have Their Heads in the Cloud?


Word Processing, Spreadsheets and Presentations that is available only through your browser. Microsoft’s office.live.com offers Word, Excel and PowerPoint this way also. Almost everyone knows about Hotmail, Yahoo Mail or Google’s Gmail. These are all Internet-based email systems that you don’t install in your office but rather access through an Internet browser or application of some kind. All of these examples are applications that live “in the cloud”.

One of the big concerns over cloud-based applications has been the security of the information. As many of us have seen in the past, social networking systems like Facebook are having its clients pay for its “free” service with a bit of their privacy. So, a new term sprang up, “private clouds”. This seems like a contradiction in terms but actually it’s referring to something of a mix of terms. A private cloud application is one which is not installed on your premises on your own servers, but rather is installed on the servers of a service provider who dedicates that server for your organization’s use. So, the privacy of the information, even though it is being transmitted in some way over the Internet, can be made much more secure.

OK! So that’s cloud computing, but I’ve yet to mention project management applications. Don’t worry, they’re there. There are a number of project management applications that are made available in both the Internet Cloud and Private Cloud models. Many clients we know are now having their enterprise project management applications such as Oracle’s Primavera or Microsoft’s Project Server hosted by a third party service provider. There are also software vendors who have designed their whole application to be available only through online subscription and your Internet Web browser. Take a peek at Canada’s AceProject based in Quebec city or Daptiv based in the US in Seattle. There are many more examples which you can find easily through an online search.

Your own applications, even though internally developed can also be moved to the cloud. There are many environments to choose from. Take a peek at Amazon’s EC2 Elastic Computing or Microsoft’s Azure environments, for examples. You can get your own virtual server at Amazon or a complete computing environment at Microsoft. More and more organizations are finding it attractive to offload their capital costs to such services in favour of regular operational costs as a method of improving cash flow and not tying up working capital in actual equipment. “Shift your CapEx to OpEx” say the salespeople.

With enterprise project management systems becoming more and more complex to support internally, there is some attraction to all of these models. Enterprise systems typically depend on a “stack” of technology. Take Microsoft’s Project Server as an example. We depend on Windows Server, SQL Server, Activity Directory, SharePoint, Internet Explorer and Exchange Server to make all the features in Project Server appear. If we can put responsibility for all of the server-based portions into the hands of a third party who specializes in such things, this can become attractive.

We estimate that more and more enterprise applications will not only become available from a cloud-based service, but that more and more organizations will insist on such applications being



subscribed to that way, so look for more and more of your enterprise level applications to appear in the cloud. That being said, I don’t expect that at any time in the medium term we’ll see a movement completely away from locally installed enterprise systems. Also, regardless of what’s in the cloud, there will always be a market for individual project management tools.

So, what should you do? For the moment, probably not much that’s different but every organization looks at their internal tools every few years and I predict that people who are looking in the 2012 to 2015 range of time will be thinking about whether to install those tools in-house or in the cloud.

There are some clear advantages to installing in the cloud and a few things to be aware of.

On the advantage side, the maintenance effort of keeping the enterprise system available, patched, upgraded, backed up and operational falls to someone else. Suppliers of such solutions also keep staff experienced in the maintenance of the tool, so you don’t need to get stressed over acquiring those skills internally or keeping them current. There’s also a financial consideration. Installation of a new enterprise system is typically quite expensive; requiring hardware, operating systems, databases and a range of other supporting technology. Expertise must often be hired to do the basic installation before you can even think about configuration of the tool for your particular use. These costs can be amortized over time in a cloud-based model and woven into the regular subscription fee. Of course, if you evaluate the total cost of ownership, it may appear more costly to pay month-by-month over the long term. You’ll need to check your business case carefully to ensure you’ve allowed for all the costs and cost savings of each option.

On the disadvantage side, you’ve got a few basic things to think about. First, working with an application in the cloud means that every one of your users has to be able to get to the cloud. That means Internet access to the application without the firewall or other restrictions keeping you from it. Security also becomes a concern. If you’ve got a contract in certain industries (like Defense or Healthcare) then you may have legal requirements for security that must be complied with. If your organization is used to doing custom modifications to your applications then that may be a factor also. Some cloud-based applications are not designed to be modified by the end-user. This may be more restrictive than you’re used to. For some applications, bandwidth and performance may be issues. One common question is to find out where the application and its associated data will be physically located. Just because a service has an address that is local to you doesn’t mean they house their data there.

Cloud-based applications are here to stay and you’ll need to include “Should we move it to the cloud?” as one aspect of future enterprise project management and enterprise project portfolio management applications.

About the Author

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

Will Project Managers Have Their Heads in the Cloud?


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

mailto:chrisv%40hmssoftware.ca?subject=

Agile


AGILE

Agile Removes Limitations


Agile Removes LimitationsIf you decide to make an Agile change in your origanization, be prepared to change the rules now.

Have you introduced a major process change like one of the agile methods – e.g., Scrum, XP, etc.?

Have you spent any time thinking about the existing rules and other structures in your organization that may need changing?

If not, you may run into trouble when agile teams bump into existing processes in your organization such as:

� Separate build/deployment processes

� Formal audit or compliance processes

� Other development teams using more traditional methods

� Centralized teams and their architecture, infrastructure, design, etc.

� Human-resources-related policies and processes like career tracks, evaluation criteria, and more

Agile Is a Change for More than Just the Development Team

Agile methods are described as software development methods. Most introductory material, like the Agile Manifesto, describe how agile teams are organized and act but don’t describe some of the things that happen outside the development teams.

When your teams start using new methods, they will act in a drastically different way from the norm, especially in an organization that has not otherwise changed. There is bound to be some conflict.

When you bump into existing processes or rules that seem to get in the way of your agile teams, you will have an important choice to make: ignore the rule, follow the rule, or try to change it.

Option 1: Ignoring the Rules – I Hope You Have Good Air Cover

This is perhaps the simplest option but one I do not generally recommend. If you have sufficient leadership support, you can be exempt from following the rules. Though this will allow you to make progress in the short term, it may cause big problems in the long term, such as:

Agile


� Breeding distrust between development teams and other groups/teams when they are excluded and ignored

� Making it easy to say that agile is just for [insert your generalization here--small, co-located, simple, unregulated, etc.] projects and doesn’t scale

� Deferring big problems, potentially allowing them to fester and build up resistance to agile in the organization

� Not utilizing the greatest source for change potential – people!

Option 2: Following the Rules – Proliferating Local Optimization

The organization created rules and processes – surely for a good reason. Shouldn’t we be good corporate citizens and follow them? In doing so, other groups and teams will take agile teams more seriously and will allow your teams to slip in alongside teams using other methods, nearly unnoticed. Depending on the rule we are dealing with, just following may be the right approach for the time being. However, before you choose to go along with the existing process or rule, consider the shortcomings of this approach:

� It introduces a high potential for local optimization – improving one part of the process while leaving other parts of the process in place. Though your teams may get more stuff done, delays will still exist in other parts of the process, possibly resulting in little or no overall improvement to the organization.

� It increases work for your teams to meet the requirements of the existing process or rule. You might find yourself creating artifacts or taking steps that don’t add value or reduce risk just to follow the process or rule. (See the example below, which focuses on an existing audit process.)

� It gives the impression that agile is only about the development teams and has no implications for the rest of the organization.

Option 3: Changing the Rules – Becoming the Agile Organization

Congratulations, you have decided to take the road less traveled and help your organization become better! Despite the difficulty of doing so, this approach will foster trust, gain additional support for the change, and leverage the great skills and knowledge of people in other teams and groups. It will also enable your teams to get more done when they aren’t burdened with process for the sake of process.

I use a fairly methodical technique for this type of situation. It is proposed by Eliyahu Goldratt[1] in his various writings. Goldratt says that organizations make rules to deal with/operate in the presence of limitations. By rules, I mean rules, processes, structures, and other arrangements and things. Technology (see the dictionary definition) improvements remove limitations. For a change to truly take hold and succeed, the rules that were made to operate in the presence of the old

Agile Removes Limitations


limitations must be eliminated or changed, and new rules created to deal with new limitations. [1]

How can we do this? Follow these steps:

� Determine which old limitations the new process eliminates. For any process step or rule that you encounter, determine why the rule exists. Techniques such as the “Five Whys” and others can help you do this. Sometimes, documentation or experts in said process can help you do this even more quickly. Consult them if possible!

� Remove the rules that existed in the past to overcome the old limitations. Agile methods provide us with principles and practices that overcome many limitations of the past. Validate that the limitations the existing process or rule was made for are handled by the new method. Ensure that those who need the existing process understand this and adapt appropriately, and help them to do this.

� Determine potential new limitations. With any new improvement comes the need to focus on different limitations. This is what continuous improvement is all about. Identify the new, important limitations and adjust your processes and rules to deal with those.

� Repeat! Repeat this process and combine it with frequent retrospection. You’ll soon be on your way to embodying continuous improvement in your organization.

All the rules that were made when older limitations existed, if they continue to be your modus operandi, will sap away the ability to improve continuously and embody the change you are trying to make, leech away energy from your change agents, and eventually result in a transition that is mediocre at best. This situation makes it appealing to create a hybrid method, such as combining the Unified Process with agile.

There are other aspects of agile transitions that are important to consider, but changing the rules is a major one that is often neglected due to how difficult it is. Any time you feel like customizing your agile process with something from your former processes, ask yourself if it is because you have found a rule that needs changing!

Reference

[1] Goldratt, Eliyahu. Beyond The Goal. Your Coach in a Box; unabridged edition (September 1, 2005).

The article was first published on StickyMinds.com.

About the Author

George Schlitz is co-founder of BigVisible Solutions, a consultancy that focuses on large-scale agile adoptions in diverse industries. Bringing knowledge of agile, lean, systems thinking, and theory of constraints to his clients. His passion is helping clients overcome the challenges of

http://www.stickyminds.com/s.asp?F=S16009_COL_2

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 [email protected].

mailto:gschlitz%40bigvisible.com?subject=

Business Analysts Mitigate Agile Project Risks


Business Analysts Mitigate Agile Project RisksNew information shows that business analysts add significant value to agile projects

The agile methodology, like many concepts, is based on an “ideal” setting or environment. In the agile domain this usually constitutes a 100% co-located team of generalists who have unfettered access to the primary business stakeholder. Working in an ideal environment makes sense when you are describing theory, but organizations can find this perfect environment unachievable due to basic business constraints: resource skill sets, location, and time

allocation. These constraints present barriers to agile adoption, can hinder productivity, cause frustration amongst the team, and can lead to project failure.

To mitigate constraints and foster the development of a simulated ideal environment agile development teams should incorporate the role of the business analyst.

The introduction of business analysts into their agile software development methodology may seem counterintuitive to Agile practitioners. After all, agile purists have been saying for years to cut detailed requirements gathering cycles out of the equation and rely on direct communication between users and developers. What some do not realize is that business analysts do more than elicit requirements and these unique skills not only adapt well to the agile methodology, but greatly improve it. In their role of developing requirements business analysts have built up core competencies such has effectively communicating with distributed resources, facilitation/elicitation, as well as a deep understanding of an organization’s business environment and enterprise architecture.

Each of these core competencies brings a unique value to agile projects. They should be leveraged whenever possible to mitigate many of the risks that agile projects traditionally face:

� Working with co-located teams

� The lack of “generalist” resources available to agile projects

� Waste caused by miscommunication with the business

� Alignment with enterprise architecture and business strategy

In reality, business analysts are not “agile road blocks”, but resources who agile practitioners can put to work.

Agile


Bring Remote Resources into the Mix

More and more businesses are adopting a ‘virtual office’ where employees work from home or remote locations. Unfortunately, this is bad news for agile teams who have become dependant on in person communication. Today’s agile development teams need to adapt to this reality, finding ways to replicate the face-to-face communication that a successful implementation of the development methodology demands.

For the business analysts these challenges are nothing new and have been overcome in the waterfall world by applying highly tuned and specialized collaboration techniques, such as business process diagrams, context models, and use cases which can also succeed in the agile environment. Through the construction of models and the introduction of basic requirements collaboration techniques, JAD sessions and virtual stand up meetings, the BA can open up lines of communication between co-located and remote resources. In this way the BA can work to simulate the team room environment using software tools and collaboration techniques to replace the whiteboards and index cards.

Put Specialists to Work

A small group of generalists, individuals who hold multiple roles on a project (design, develop, test, and deployment), are the ideal team for projects following the agile methodology. Unfortunately, generalists are far and few between making them difficult to hire. At the same time training generalists is not easier, requiring employees to complete multiple projects in numerous roles to build their skill sets. In most organizations not all agile project team members will be generalists. For agile projects to succeed without the benefit of generalists they need a bridge builder, someone who can work and communicate across multiple disciplines while ultimately keeping concerns of the business in the forefront.

Business analysts bring a breadth of knowledge to bear on software projects. In their role as a communicator and liaison they are tasked to work with developers, testers, implementers, managers, and almost all roles in the software development lifecycle. This interaction has given them a wide breadth of knowledge over the entire SDLC. While they may not know all of the intricacies related to the tasks associated with these roles or be able to perform them on their own, they can provide a bridge of communication to resources that can. The use of generalists on agile projects is ideal, because they have a depth of project experience and knowledge that increases their productivity. If we can inject some of that project knowledge through an effective liaison to other project members we can extend the reach of agile development by incorporating staff which normally would not be equipped to take on all development tasks. This new resource allocation reduces project and training costs will minimizing effects on productivity.

Business Analysts Mitigate Agile Project Risks


Communicate Effectively with the Business

Agile methodologies minimize risk through the introduction of short iterations or sprints for developing and deploying software. The underlying concept behind this approach is that if a business user or stakeholder does not approve of the software solution, it can be quickly changed in the next iteration. This approach works when experienced developers know the facilitations skills to elicit a potential solution from the business users. However, if the agile developer was able to gain a clear understanding of the business need and provide a useful solution project effort is wasted twice. Once on the sprint which got the solution wrong and then again on a sprint to make the correction.

Constant, direct, and meaningful communication between business stakeholders and developers reduces waste caused by misunderstood requirements, but only if that communication is effective. A frequent hurdle presented by this concept is that the role of requirements gatherer can be unfamiliar territory for developers. In many cases they do not know which questions to ask, what information to capture, or how to communicate with the stakeholders.

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

Think Beyond the Project

Even when agile developers are able to skillfully communicate with their business users the conversations tends to center around topics directly related individual issues surrounding the current project or system under development. Specific user needs, related business problems, and possible solutions are exactly what should be discussing, but this isn’t always the entire picture. That being said, it is a common occurrence for developers and business users to take a narrow point of view when constructing a new system, focusing on specific features and challenges faced by the user who is sitting in front of them. The problem with this approach is that an enterprise point of view is not considered. This lack an enterprise architecture focus leads to duplicate data, siloed systems, and missed opportunities for cross-business integration.

By assigning a senior business analyst, to serve as an enterprise architect, to the agile project the team gains a 30,000 ft view of a project including a perspective of how it relates to the organization as a whole. Bringing a sophisticated level of business knowledge to the project, the BA’s point of view provides business level context to the problem and the solution. This guidance

Agile


ensures that the technical solution is inline with the current business objectives, constraints, and that the solution can be incorporated into the established enterprise architecture.

One method of ensuring alignment is the use of the Business Driven Development, a practice which focuses on building technical solutions that directly satisfy business requirements. To ensure alignment to business requirements a model-driven approach is leveraged which takes into account the business strategy, requirements and goals and then transforms them into an IT solution.

Agile development is not perfect. As with any methodology there are challenges. But, these challenges can be mitigated. The introduction of a business analyst, and their experience in communication, elicitation, and enterprise architecture, to an agile development team can reduce risks and improve project success and agile adoption rates.

We often use the acronym “BA” as short hand for Business Analyst. But, when properly incorporated into a project BA stands for Better Agile.

About the Author

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

mailto:mleach%40doreenevans.com?subject=

mailto:mleach%40doreenevans.com?subject=

http://www.doreenevans.com

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


The Marriage of Lean, Scrum and Extreme Programming (XP): How to Align Agile Across an OrganizationIncrease your chances of adoption, productivity and general success by aligning Agile methods for Lean, Scrum and Extreme Programming

Over the years, many flavors of Agile have emerged: Scrum, Lean, Feature Driven Development (FDD), Agile Unified Process (AUP) and Extreme Programming just to name a few. These methods have numerous complementary and distinguishing features, but the gamut of choices can be confusing and disorienting - as if being told to choose the best from 31 flavors of ice cream. Return on Investment (ROI) is important to me, so Lean must be the answer. But wait, I also want to be agile with my business

priorities so I’ll choose Scrum. On the other hand AUP facilitates scaling, so... we are left wanting a simple question answered: “Which Agile method should I choose for my organization?”

I have found that one can view an organization at three levels: the Executive/Project Management Office (PMO), the Management/Project and the Development/Delivery. While the organization typically (or hopefully) has aligned goals, each level has their own sub-goals, focus and deliverables. A strategy-focused executive’s eyes will glaze over if you evangelize the virtues of Extreme Programming (XP) such as continuous integration; these technical details are so foreign to the executive that you might as well be discussing the virtues of object-oriented programming. However, the executive will hungrily ask for more information and how fast can we get started if you describe creating greater shareholder value by removing waste and optimizing across the organization, i.e. Lean.

So, as Agile matures within organizations we find the question, “Which Agile method do we choose?” is revised to, “Which Agile METHODS do we choose?” I have found that the various organizational levels align near perfectly with three specific Agile Methods: Lean, Scrum and Extreme Programming. In this article, we will look how to best align Lean, Scrum and XP across an organization.

Agile


The Organization as a System

Imagine on an episode of the T.V. show “House M.D.” the brilliant, but curmudgeonly, Dr. House sees a patient suffering from severe lower back pain. She has suffered for years and gone to numerous doctors, but nothing has worked. After a cursory glance, House asks her to stand up and attempts to balance a book on her head. The book slides down to her left side and falls to the ground. House tries again and the book once more slides down to her left side. House stares at her and tersely says, “What you need are new shoes.” “What?” she surprisingly asks. “New shoes! Your left leg is slightly shorter than your right. You need a lift added to your left shoe and then your back will be fine,” House states as he walks out of the office. While the other doctors neglected to detect the cause of her pain, House again proved his reputation as an unparalleled diagnostician by looking at the whole system and relating her shorter leg to her back pain. He performed “System Thinking” (Smith, 2007).

What is “System Thinking?” Simply put, System Thinkers “view the world, including its organizations, from a broad perspective that includes structures, patterns and events, rather than just the events themselves” (McNamara, 2005). Based upon System Theory, System Thinkers understand that “like a living body, an organization is best understood as a whole, rather than in parts.” For example, breaking up an elephant doesn’t create a bunch of little elephants…just a mess (Smith, 2007). The concept of an organization as a living organism inspires one to look at a company’s organizational levels not as mutually exclusive divisions, but rather as mutually dependent sections of the whole. In following sections we’ll see why this view facilitates Agile successfully fitting across an organization, but first let’s look at a simplified breakdown of an organization into levels.

On the Level (of an Organization)

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



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

Having defined the three types of organizational levels, let’s move onto narrowing down the numerous Agile processes.

Choosing the Right Agile (Let The Right Agile In)

I often hear colleagues new to Agile proudly declare, “We’re now practicing Agile at my company” or “Our projects are now Agile projects.” “Fantastic,” I usually reply, “What type of Agile did you go with?” More often than not they answer, “Um, well, Agile. There’s more that one?” My answer: “Yes. Yes, there certainly are.”

Agile, as stated in the seminal Manifesto for Agile Software Development, is a set of principles – a philosophy rather than a step-by-step process. Heavyweight processes (Waterfall or SDLC) dominated the development world and were considered, well, heavy. Managers soon began playing with the notion of doing more with less. Over time, lightweight processes emerged that focused on collaboration, communication and adaptability. Finally, in 2001, the Agile Manifesto crystallized the common philosophical concepts of now familiar Agile process – Scrum (1995), XP (1996) and DSDM (1995) to name a few – into a unified set of guidelines and statements.

However, this begs-the-question, “Which of the many Agile methods do we choose?” While over time we may see several Agile processes fall-out of favor, for now we have many types to choose from each with unique characteristics and benefits. Three Agile processes standout as ideally differentiating: Lean, Scrum and Extreme Programming (XP). Let’s take a quick look at their key features (Lane, 2006):

Agile


As you can see, these three types of Agile processes each have unique strengths that compliment one another. However, like any good superhero movie, the origin back-story usually gives us great insight into our hero’s motivation (if the robber hadn’t killed Peter Parker’s Uncle Ben, our superhero Spiderman would never have been born). So, let’s take a quick look at the three Agile processes.

Lean

Lean originated within the Toyota production line as a way to remove waste, optimize across the organization, flow value from demand and focus on those who add value. The success of Lean at Toyota led innovators such as Mary and Tom Poppendieck to begin applying Lean to software development. They found that Lean, as a set of thinking tools rather than a distinct process, could greatly improve the efficiency of the software delivery lifecycle and help “shorten the time from problem recognition to software solution” (Poppendieck, 2002).

Lean development promotes seven key principles:

Lean thinking has been applied across a myriad of industries and has been found to regularly produce significant customer value add. Let’s look at an interesting example with the recent



decision by Spirit Airlines to begin charging $45 for carry-on overhead luggage (no charge for luggage that fits beneath the seat). At first glance you might think this decision yet another airline tactic to penny-pinch the customer, but consider for a moment the three main concerns of a frequent flyer: speed, comfort and cost. When the overhead bins are stuffed, the three main customer concerns are negatively affected. First, the boarding and deplaning takes longer. Reduced speed and greater cost emerges as an issue the longer the plane sits idle. Second, customers need to check carry-on bags that don’t fit in the overhead bins. Have you ever boarded a plane and found all the overhead bins were already full (try as you might to stuff your bag into that too small of a space)? Finally, the plane weighs more. It makes sense: more weight, more fuel, more cost. Spirit’s lean decision to charge for carry-on baggage arguably creates greater customer value and choice. As Spirit’s Chief Operating Officer Ken McKenzie put it, “Bring less, pay less. It’s simple” (Huffman, 2010).

Scrum

The Scrum process provides a simple framework that facilitates team organization and getting high-quality work without sacrificing productivity (Sutherland, 2007). The name Scrum derives from the rugby term that refers to the “mechanism to restart the game after an infraction. It is the general idea of a team huddling together to move the ball toward the goal” (Lane, 2006). Like Lean, the concept of Scrum originated in the manufacturing world. At the Easel Corporation in 1993, Jeff Sutherland first applied the Scrum concept to software development. Finally, in 1995, Ken Schwaber and Jeff Sutherland formally introduced the Scrum process after analyzing common development processes and concluding that they were not suitable for empirical, unpredictable and unrepeatable processes (Coetzee, 2008).

Scrum focuses on team organization (ScrumMaster, Product Owner and Development Team) and practices (Daily Scrums, Sprints and Retrospectives). Scrum has an interesting delineation between those committed to building and delivering software frequently (the “Pigs” – Product Owner & Development Team) and those interested in the project but not committed to delivery (the “Chickens” – Stakeholder & Managers). The terms “Pigs” and “Chickens” comes from a classic joke on commitment, wonderfully illustrated below by Mike Vizdos and Tony Clark:

Agile


Extreme Programming (XP)

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

XP contains a lot of similar Scrum practices with the engineering elements that Scrum is traditionally missing.

Aligning Agile Across an Organization (If the Shoe Fits…)

At this point, we’ve begun to see that the three organizational levels (Executive, Project Management and Development) align quite nicely with three specific Agile process (Lean, Scrum and XP), respectively. While all of the Agile processes have commonality, their sweet spots are attuned to specific organizational levels: different “views” for different audiences. Lean shines when applied to those with a strategic, organization and shareholder value focus: the Executive. Scrum shines when applied to those with a team organization, management and project delivery focus: the Project Management. Extreme Programming shines when applied to those with a development delivery and tactical focus: the Development. Diagram 1.5 illustrates this concept.

Putting on our System Thinking caps for a moment (and never taking them off), we must remember to address the whole system and not individual parts. Apply Agile across an organization and not at any one single organizational level else we risk organization goal misalignment and an increased chance of failure, or at least less successful than we could have been.



For Your Consideration

What about the technicalities of managing three Agile processes across an organization? In other words, how do you actually make it work? While that answer goes beyond the scope of this article, please consider the following as a potential guideline.

As we all know, companies’ culture and organizational breakdown can differ greatly. At one financial company where I worked, the high-level Managing Directors often boasted that they could still code with the best of them. The corporate focus leaned more towards a tactical mind-set, i.e. XP. In other words, a company’s unique culture and organization will determine the appropriate Agile fit; whether applying Lean, Scrum and XP to the afore mentioned three organizational levels or a mixture of Agile process to the unique corporate tiers. So remember two things: first, Agile promotes fluid and adaptable processes, thus you can practice the “Agile Way” of keeping what works and leaving out what doesn’t. Second, always “System Think” and apply across the organization and not to a single part.

Final Thoughts

We can view an organization at three levels: the Executive/Project Management Office (PMO), the Management/Project and the Development/Delivery. These levels, each with their own focus, goals and mind-sets, perfectly align with the sweet spots of three Agile processes: Lean, Scrum, and Extreme Programming. By applying these three processes across the organizational levels (System Thinking – applying not just to a single organizational level), we increase our chance of adoption, productivity and general success.

I believe that we are on the verge of inventing a new way of looking at Agile: a maturation and simplification of Agile from numerous processes to a few or even one. Perhaps even a new process might emerge that addresses the needs across an organization. However, creating a new process will take significant fortitude and community accord. As Albert Einstein noted, “Three Rules of Work: out of clutter find simplicity; from discord find harmony; in the middle of difficulty lies opportunity.”

Aligning Agile Across an Organization (If the Shoe Fits…)

At this point, we’ve begun to see that the three organizational levels (Executive, Project Management and Development) align quite nicely with three specific Agile process (Lean, Scrum and XP), respectively. While all of the Agile processes have commonality, their sweet spots are attuned to specific organizational levels: different “views” for different audiences. Lean shines when applied to those with a strategic, organization and shareholder value focus: the Executive. Scrum shines when applied to those with a team organization, management and project delivery focus: the Project Management. Extreme Programming shines when applied to those with a development delivery and tactical focus: the Development. Diagram 1.5 illustrates this concept.

Agile


Putting on our System Thinking caps for a moment (and never taking them off), we must remember to address the whole system and not individual parts. Apply Agile across an organization and not at any one single organizational level else we risk organization goal misalignment and an increased chance of failure, or at least less successful than we could have been.

For Your Consideration

What about the technicalities of managing three Agile processes across an organization? In other words, how do you actually make it work? While that answer goes beyond the scope of this article, please consider the following as a potential guideline.

As we all know, companies’ culture and organizational breakdown can differ greatly. At one financial company where I worked, the high-level Managing Directors often boasted that they could still code with the best of them. The corporate focus leaned more towards a tactical mind-set, i.e. XP. In other words, a company’s unique culture and organization will determine the appropriate Agile fit; whether applying Lean, Scrum and XP to the afore mentioned three organizational levels or a mixture of Agile process to the unique corporate tiers. So remember two things: first, Agile promotes fluid and adaptable processes, thus you can practice the “Agile Way” of keeping what works and leaving out what doesn’t. Second, always “System Think” and apply across the organization and not to a single part.

Final Thoughts

We can view an organization at three levels: the Executive/Project Management Office (PMO), the Management/Project and the Development/Delivery. These levels, each with their own focus, goals and mind-sets, perfectly align with the sweet spots of three Agile processes: Lean, Scrum, and Extreme Programming. By applying these three processes across the organizational levels



(System Thinking – applying not just to a single organizational level), we increase our chance of adoption, productivity and general success.

I believe that we are on the verge of inventing a new way of looking at Agile: a maturation and simplification of Agile from numerous processes to a few or even one. Perhaps even a new process might emerge that addresses the needs across an organization. However, creating a new process will take significant fortitude and community accord. As Albert Einstein noted, “Three Rules of Work: out of clutter find simplicity; from discord find harmony; in the middle of difficulty lies opportunity.”

Bibliography

� Carnegie, D. (1981). How to Win Friends & Influence People. New York, NY: Pocket Books.

� Coetzee, L. (2008, Oct 6). What is Scrum? Retrieved from Swat Blog

� Huffman, M. (2010, Apr 7). Spirit Airline Charges For Carry On Bags. Retrieved from Consumer Affairs

� Lane, R. C. (2006, Oct 17). A Practical Guide to Seven Agile Methodologies. Retrieved from devX

� McNamara, C. (2005 Feb). Thinking About Organizations as Systems. From Free Management Library

� Poppendieck, M. (2002). Principles of Lean Thinking. Retrieved from Lean Software Development

� Smith, K. M. (2007 28-Sep). Understanding Your Organization as a System. From Ezine Articles

� Sutherland, J. (2007, Oct 14). The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process.

� The Free Dictionary. (n.d.). Scrum. Retrieved from The Free Dictionary

About the Author

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

mailto:gbourne%40gmail.com?subject=

Agile


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

Having troubles introducing Agile Development on your custom software development projects? Why not try moving to it gradually?

Implementing an Agile Development methodology on a custom (or bespoke) software development project can be difficult and many organizations new to the agile methodology struggle to adopt it. One of the big ‘problems’ with Scrum (a flavour of Agile Development) is that project-related issues come to the surface

early because the team must deliver potentially release-able software within a month. Those issues in combination can seem insurmountable to those new to Scrum.

Typical issues/obstacles that arise include:

1. Lack of business ownership and the inability to make decisions,

2. Limited business buy-in into the concept of Agile,

3. Team communication, individual skills, and team fit,

4. Lack of trust in the team by the business.

In a traditional (waterfall) project, the team can spend months on design and when development begins they may start with the low complexity features, thereby not identifying issues until it is too late; forcing the project to run over-budget and/or delivering a solution that doesn’t meet the users’ needs.

When introducing Agile Development, organizations often attempt to tackle all of these issues head on and get overwhelmed with the new methodology, then choosing to revert back to what they are familiar with.

Why not introduce Scrum in stages to enable an organization to deal with issues one at a time and gain the benefits associated with solving each issue gradually?

Based on my experience as an Agile/Scrum Coach, I have found that introducing each stage below gradually over a number of months can work effectively for an organization that is

Introducing Agile Development? Move Gradually!


struggling with Agile Development.

This article outlines a number of stages that a project team should go through in the introduction of Scrum. Each stage is summarized and then outlined in more detail below.

The first stage introduces prioritization of requirements, focusing only on the highest priority ones within a time-boxed two week sprint. Introducing prioritization can be difficult and issues with lack of business ownership and inability to make decisions must be overcome to enable you to complete this stage. The benefit gained is the ability to re-focus based on changing priorities.

At the second stage, you will overcome the obstacle of gaining business buy-in into the concept of Agile Development and ensure that the business agrees that quality and high priority business requirements are the top priority – over a detailed plan. You will have introduced estimation based on story points which will give the business improved control of the project in making decisions related to priority.

At the third stage, you will ensure the team is collaborating more closely; overcoming team communication and development skills deficiencies. You will have reduced the number of defects and the team will produce higher quality software quickly.

At the fourth and final stage, proper user stories and acceptance tests written by a Business Analyst will be introduced and the software will be frequently demonstrated to users so that their feedback can be incorporated. The business must learn to trust the team and agree to minimal documentation and sign-off. Once complete, teams are able to deliver software that is more closely aligned with what the user wants.

Each stage is outlined in more detail below:

Stage 1: Focus on the highest priority requirements within a time-boxed sprint

In my opinion, the biggest benefit to be gained by introducing Agile Development is the ability for a project team to re-focus based on changing priorities (and changing requirements). To gain this benefit, the first step is to focus on only the top priority requirements in the first two week iteration (called a sprint in Scrum).

Work closely with the business representative to ask the simple question ‘what happens if we don’t do that?’ For teams that are less Agile, they will quickly realize they are working on a number of low priority requirements that do not necessarily provide much up-front benefit to the user.

The main goal of the initial prioritization should be to identify the minimum number of features required for the product to be released and demonstrated to the user. Teams can often think only of the end product that includes all features.

Agile


Once the first logical chunk of work has been identified, but before any development work begins, sit with the team to break down the requirements into tasks (referred to as sprint planning in Scrum). Get team members to commit to estimates so that everyone is aware of what they must do in that first time-boxed sprint. It is a good idea to use a board or software to track the tasks and ensure they are completed within the sprint.

The new focus for the business representative should be to document detailed requirements only for the next sprint (the next couple weeks). They must not spend a large amount of time writing specs for requirements that aren’t coming until the next release since this is often wasted effort as requirements and scope change.

Scrum features introduced at this stage

If you are familiar with Scrum, note that at this stage, we have not introduced many of the formal rules of Scrum. We have identified the Product Owner by asking the business to prioritize requirements using the Product Backlog. Prioritized requirements have been divided into a small chunk of work called a sprint and the team has performed sprint planning and committed to accomplishing their own tasks. In a future stage, they will commit to work as a team.

At the end of every sprint the software is released for testing. At this stage, I wouldn’t recommend attempting to release the software to testers multiple times throughout the sprint.

Issues overcome at this stage

Issues with decision making and business ownership must be overcome to enable you to complete this stage. It is often very difficult to identify the appropriate Product Owner who is respected by the business. In my experience with custom development projects, the best Product Owner is often a Senior Manager and therefore Business Analysts are required to represent that person at a detailed project level.

Developers always tend to under-estimate their work. When I start introducing Scrum I continually coach the developers to ‘over-estimate’ their tasks during sprint planning, but in the first few sprints individuals often over-commit as they get used to the concept of a time-boxed sprint.

Benefits gained at this stage

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



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

Now that the business requirements have been prioritized, and the team is working on the most important items using sprints, it is important to communicate this to the project sponsor.

Some coaches will suggest that this should be the first stage of introducing Scrum/Agile development into an organization. I recommend that this is not done until after the first stage, because until the issue encountered in stage 1 related to decision making and business ownership is resolved, there is nothing to get agreement on from the project sponsor.

Once the requirements have been prioritized, it is important to ensure that the project sponsor agrees with the concept of Agile Development. The biggest advantage of Agile is that the team will provide the highest priority business requirements quickly and the solution will be of high quality. The biggest ‘disadvantage’ of Agile Development is that because quality is not negotiable, if issues arise, the lower priority requirements will be moved further out on the plan. In other words, they no longer have the Gantt chart that predicts (often incorrectly) exactly what features are scheduled when.

Instead of a detailed Gantt chart, communication with the Project Sponsor should include high-level goals (outlined in order of priority) planned for the next release. To be able to provide the goals planned for the next release, the developers must provide some high level estimates (story points – relative point system to estimate development time) for each requirement. Based on this the business is able to better prioritize and you should be able to come up with a rough idea of which requirements will make it in to the release.

The most important concept for the project sponsor to understand is the ‘Iron Triangle’, as depicted in Figure 1. One of the basics in Project Management is that with any project, if the scope (or the amount of features implemented) is increased then cost and/or time must also increase.

The key thing to focus on with Agile Development is that because you have outlined a fixed release date and have a defined team, time and cost will remain the same and scope is what changes. The Project Sponsor must understand that the goals for the release have been prioritized and if issues arise, the quality of the product does not suffer and we still meet the published release date – but features can be moved out into a future release.


At this stage, we have introduced estimating the product Figure 1 – The Iron Triangle

Agile


backlog requirements using story points. I explain to the business the concept of high-level planning using Scrum in that a release is made up of a certain number of sprints each with prioritized features. You can also start measuring team velocity using the burn-down chart if the project sponsor is looking for proof of productivity improvements.


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


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

Stage 3: Improve Team Collaboration and Software Quality

The team now knows what high priority business requirements they should work on and the pressure of meeting an unrealistic project plan; which doesn’t accommodate for unforeseen issues and changing requirements, has been removed. They should already be feeling happier – so now is the time to get them working together more closely to help improve productivity.

Ideally the team should already be co-located, including Business Analysts, Testers and Developers. It is now time to introduce the ‘daily stand-up’, and the sprint retrospective to enable the team to talk about what they did well and where they can improve.

In the first stage, developers started committing to their own estimated tasks at the beginning of each sprint. Once that is working well, you can enable team members to select their own tasks from the planning board during the sprint. At the beginning of a sprint, rather than committing to individual tasks, they will be committing as a team to complete all of the user stories, which encourages self-management. The developers should help each other solve issues and collaborate on the best approach for design using pair programming where it makes sense.

Not only must the developers communicate more with each other, but the communication must spread to the Testers and Business Analysts as well. This is the only way we can define what should be built and tested.

When I first started coaching one team, someone told me that he felt like software testing was like going into an exam where they had no idea what to study since they weren’t sure what would



be covered. This was because testers were ‘being creative’ and coming up with ‘new and crazy’ scenarios to test. There were so many ‘defects’ that every few weeks there would be a long defect prioritization session. This type of defect prioritization should never be required.

Instead, everyone should be very clear before development begins what will be tested so that the developers can write code that meets the requirements and defects are therefore minimized.

If the goal is high quality software or zero defects by the end of the release. The only way to accomplish this is to ensure that defects raised are ‘real defects’ i.e. there is a business requirement (or acceptance test) that is not currently being met. To ensure defects are ‘real’, testers must communicate regularly with the testers and developers. If in doubt, BEFORE raising a defect the tester must clarify that the issue they are raising really is a defect. If it is a new feature, it is instead added to the product backlog.


The team now takes part in a daily standup for fifteen minutes or less at the same time every day. They are sharing tasks and becoming more cross-functional, working together to identify how they can improve through the introduction of sprint retrospectives.

The team is using acceptance tests to more clearly state the ‘definition of done’ so that both developers and testers know exactly what is expected. Software can be released to testing throughout the sprint rather than at the end of the sprint and defects should always be given top priority over new features.


At this stage the team must overcome people issues. I’ve worked with teams where there were team members that either did not have the skills or the personality to work on a Scrum team. If they don’t have the skills, that is apparent very early on because they are not able to deliver the software within the sprint. Issues with personality I’ve seen include failure to communicate with the testers and business analysts due to the need to work independently. That doesn’t work with Scrum.

I have worked with a team that didn’t have any Business Analysts – just a Product Owner who was not available the majority of the time. In this case, we attempted to have the testers and developers write acceptance tests together at the beginning of a sprint. This was very difficult and productivity improved dramatically when Business Analysts were added to the team.


Developers, testers and business analysts are all working towards the sam objectives in each sprint which will enable you to reach the goal of zero defects at the end of each release (and

Agile


hopefully each sprint). This high-quality software will be provided more quickly due to increased team velocity due to sharing tasks and increased communication.

Stage 4: Ensure requirements are user stories that incorporate real feedback

Now that the team is developing high quality software and productivity is starting to improve it’s extremely important that you ensure that what they are building is exactly what the user wants.

In traditional projects, a lot of up-front analysis is done and requirements may be outlined either as technical or functional features for the developers to code, with no explanation of who needs it and why. Because of this, the team may still be building software that does not meet the user needs due to misinterpretation of the user (by the Business Analyst) or misinterpretation of the Business Analyst (by the Developer).

At this stage, it is important that the Business Analyst steps back and examines the high priority functional requirements scheduled for the next iteration to ensure that they fully understand the requirement and are communicating it clearly.

The best way to minimize misinterpretation is to write requirements as user stories. They should be worded in the following way: ‘As a’ user ‘I want to’ do the following ‘so that’ the following benefit can be met. The Business Analyst must make it clear what is expected at the end of a sprint – also referred to as ‘the definition of done’. To communicate this clearly acceptance tests should be written.

To ensure that the team has actually developed what the user wants, at the end of each sprint, demonstrate the solution and get feedback from the user! For software that is already in production, ensure there are frequent releases so that real user feedback can be incorporated. Note that the best way to enable your team to release software frequently is to introduce automated regression testing.


Business Analysts must learn to write requirements in a new way and the business must agree to minimal documentation and sign-off. This is only possible if you have someone responsible for the product ownership that the business trusts.

The best way to demonstrate that limited documentation still works is to demonstrate the solution to the users regularly and incorporate their feedback – this is a key feature of Scrum. Ideally, the team has been producing working software at the end of every sprint, but if they haven’t been, now is the time to enforce this.




It can be difficult to get organizational buy-in on limited documentation. Many large organizations are resistant to this type of change due to lack of trust in the team.

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


The benefit gained at this final stage is that the software developed better meets the business needs. Expectations are appropriately set with the users and the software meets those expectations.

Conclusion

If your organization is having troubles introducing an Agile methodology on a custom software development project, try introducing the above stages gradually. By introducing only one stage, you can still gain the most important benefits of Scrum – the ability to re-focus based on changing priorities. Once your team has overcome the issues associated with that stage, you can move onto further stages and gain added benefits with each issue you work through.

In my experience, there are a large number of organizations that are adverse to change – especially large corporations and government organizations. In these types of organizational cultures, it is best to deal with one obstacle/issue at a time rather than getting overwhelmed with all issues at once.

I recommend that you first ensure the business is taking ownership and making decisions. I think it is best to focus on overcoming this obstacle first before moving onto the second stage.

Once a Product Owner has taken control of a prioritized product backlog and the team is working on only the top-priority requirements, it is then time to explain the benefits of Agile development to the business. Once they have bought-in to Agile and are given more control over the project, it is then time to focus on improving software quality.

Improving team collaboration will ensure that developers, testers and business analysts are all working towards the same objectives in each sprint will enable you to reach the goal of zero defects at the end of each release.

The final goal is better met user expectations which I think is only possible through the introduction of user stories, acceptance tests and regular demonstrations with users. Getting the business to agree to new processes around documentation can be difficult as it requires that

Agile


trust in the team is established – which again is difficult to do until the initial obstacles have been overcome.

About the Author

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

http://www.lplconsulting.com.au

http://www.lplconsulting.com.au

Evolving from Traditional Project Management to Agile


Evolving from Traditional Project Management to AgileAre traditional project management techniques failing? It’s time to add Agile Project Management into the mix.

Traditional project management involves very disciplined and deliberate planning and control methods. With this approach, distinct project life cycle phases are easily recognizable. Tasks are completed one after another in an orderly sequence, requiring a significant part of the project to be planned up front. For example, in a construction project, the team needs to determine requirements, design and plan for the entire building, and not just incremental components, in order to understand the full scope of the effort. Traditional project management assumes that events affecting the project are predictable and that tools and

activities are well understood. In addition, with traditional project management, once a phase is complete, it is assumed that it will not be revisited. The strengths of this approach are that it lays out the steps for development and stresses the importance of requirements. The limitations are that projects rarely follow the sequential flow, and clients usually find it difficult to completely state all requirements early in the project. This model is often viewed as a waterfall.

Today, business processes are more complex, interconnected, interdependent and interrelated than ever before. Additionally, they reject traditional organizational structures in order to create complex communities comprised of alliances with strategic suppliers, outsourcing vendors, networks of customers and partnerships with key political groups, regulatory entities, and even competitors. Through these alliances, organizations are able to address the pressures of unprecedented change, global competition, time-to-market compression, rapidly changing technologies and

Figure 1: The Waterfall Project Life Cycle Model

Agile


increasing complexity at every turn. Because of this multifaceted nature of businesses, projects that implement new business systems are also more complex.

For years, economists have been warning that success in a global marketplace is contingent upon the capability to produce small batches of tailored products on a tight schedule to meet growing demands in emerging markets. However, huge cost and schedule overruns have been commonplace in the past.[1] Looking at the numbers, the past project performance record is troubling:

� $80 -145 billion per year is spent on failed and cancelled projects (The Standish Group International, Inc.)

� 25% - 40% of all spending on projects is wasted as a result of re-work (Carnegie Mellon)

� 50% are rolled back out of production (Gartner)

� 40% of problems are found by end users (Gartner)

� Poorly defined applications have led to a persistent miscommunication between business and IT. This contributes to a 66% project failure rate for these applications, costing U.S. businesses at least $30 billion every year (Forrester Research)

� 60% - 80% of project failures can be attributed directly to poor requirements gathering, analysis, and management (Meta Group)

� Nearly two thirds of all IT projects fail or run into trouble. (See Figure 2 for the results of the 2006 CHAOS Survey.)

Improving these performance records is a goal for any organization. However, if traditional project management is somewhat ineffective, it’s time to examine other methods of designing and delivering projects.

Agile Project Management

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

Figure 2: Project Performance Track Record – The Standish

Group 2006 Chaos Report



developers are co-located; incremental feature-driven development is possible; and visual documentation (cards on the wall vs. formal documentation) is acceptable. Figure 3 depicts the

Agile Development Model.

The Agile approach consists of many rapid iterative planning and development cycles, allowing a project team to constantly evaluate the evolving product and obtain immediate feedback from users or stakeholders. The team learns and improves the product, as well as their working methods, from each successive cycle. After a streamlined planning, requirements definition and solution design phase is completed to get the project underway, iterations of more detailed planning, requirements, design, build and test take place in waves. This approach allows for immediate modifications of the product

as requirements come into view. APM requires a dedicated full-time project team that includes a customer or end user, where team members work from the same location.

The Agile Project Management Environment

Unlike traditional project management, which emerged from the construction, engineering and defense industries and dates back to the 1950s, APM was born in the twenty-first century. In 2001, prominent software developers from both IT and software engineering domains, convened to arrived at a consensus on how the software development industry could produce better results. This meeting produced the Manifesto for Agile Software Development, which states that the “highest priority is to satisfy the customer through early and continuous delivery of valuable software.”[3]

APM development is conducted collaboratively, with a small co-located team. This core team usually consists of two developers who write code in pairs (for quality control), the customer/end-user, IT architect(s), a business analyst and a project manager. The work is accomplished through a series of sessions where the team writes code, then tests working modules of the system and repeats the process. There is minimal documentation as the team relies almost exclusively on informal internal communication. Again, this differs from the traditional approach where a considerable amount of time is invested in planning and a significant amount of requirements documentation is produced. The Agile team identifies and prioritizes the features based on

Figure 3: The Agile Project Life Cycle Model

Agile


business value, and after high-risk components of the system are produced, works on the highest value features first. This approach works if the solution can be delivered incrementally to the customer. If this is not possible, features still can be built incrementally and then integrated into the first release of the system.

Agile Management Components

There are several key elements that provide the basis for APM. It is important to note that these techniques can also be used in traditional software development methods to improve project performance. They are:

1. Visual control

This is a “cards-on-the-wall” method of planning to assist a team in organizing the work of the project. For example, one successful Agile project team placed different color groups of cards that represented the features of the solution on the wall. The features that were designed, developed, tested and in production were one color, the features that were designed, built, tested but not yet put in production (but ready to go) were another color. The team was able to see at a glance where they were with each feature set. Visual control is a valuable technique for all projects, since it ensures that every member of the team views the project the same way.

2. Co-located high-performing teams

In Agile development, all the key team members are co-located, including the customer/end-user, preferably in a work room. This approach greatly increases the quality of coordination and communication. However, this may represent a significant cultural change for IT developers. In traditional development methods, the developers typically work independently, and rarely interact with the customer until the solution is fully developed. Since project managers are responsible for building a high performing team, they need to ensure everyone is working well together and that they have been assigned developers who truly can work in this collaborative manner.

3. Test-driven development

In cases when the customer is having a difficult time articulating requirements, Agile teams often use test-driven development. Using the same successful Agile project team mentioned above as an example, the test cases were often developed first, and then the team backed into the requirement. This obviously requires more iteration between requirements, design, development and test. The entire four-stage cycle is collapsed. In any case, Agile teams almost always develop test plans at the same time they define requirements; if a requirement isn’t testable, then the requirement is not yet fully developed. This is a best practice that can be used in traditional development to ensure requirements are complete, accurate and testable.



4. Adaptive control

Everyone on the team is constantly adapting, which may make some team members nervous, especially those that crave structure. Because of this dynamic environment, the project manager needs to be seen as a leader, not a taskmaster. Instead of setting rigid instructions for the entire team to follow, the project manager facilitates the team in establishing working relationships, setting ground rules and fostering collaboration. Agile team members continuously adapt to improve their methods as they incorporate lessons learned from the previous cycle into the next iteration, also a best practice for any project.

5. Collaborative development

APM relies on collaboration among all team members to deliver the results, capture candid feedback and implement learnings on the next iteration of the solution. This is one of the strengths of APM - constant feedback and improvement. The project manager completes the initial planning and the business analyst defines and prioritizes the solution features in collaboration with the customer and technology representatives. Then the Agile project teams collaborate on the design, development, testing and reworking of each incremental build. It is this constant collaboration with the customer that promotes project success.

6. Feature-driven development

This practice greatly reduces complexity, because it allows the team to focus on one feature and only one feature at a time. For example, one team is working on Feature #4 and that’s the team’s only focus. They don’t concern themselves about Features #1-3. It is the business analyst and project manager who ensure the next feature in the backlog is truly the next priority, based on business value and risk. Typically, high-risk components or core infrastructure pieces are built first, and then everything else is prioritized based on business value. The goal is to build the feature-driven components with only a one-way dependency to the core system; therefore, specialized components are independent of each other and can be created in any order or even in parallel.

7. Leadership and collaboration rather than command and control

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

Agile


8. Move from C (cost) to R (revenue) focus

Features are prioritized based on value, such as increased revenue or market share. It’s the business analyst’s role to ensure the Agile project team is not investing too much into the development of the new solution. If so they will have eroded the business case and the project will cost more than the organization will gain. While the project manager focuses on project costs, the business analyst focuses on the total cost of ownership that includes not only the development or acquisition costs of the new solution, but also the cost of operating the system after it is deployed.

9. Lessons learned

After each cycle, the team holds a lessons learned session to determine what they can do better on the next iteration. As the team learns, it adapts how the members are working together to continuously improve team performance.

The Value Proposition

“The traditional project management approach,” Augustine reports, “is a linear approach where you try to get it all done at one time. You do a lot of very detailed planning at once up-front and then deliver it in what’s known as the ‘Big Bang’. That industrial age thinking has spilled over from software development to other projects as well.” This is the heart of the difference between Agile and traditional project management.

The ‘Big Bang’ now comes from the greater flexibility and collaboration APM provides. “Just enough” planning is done up-front. As each increment of the system is built, the team gathers input and learns from customer feedback. Since the customer sees and/or experiences a working prototype, he or she is better able to refine or redefine requirements and describe to the team what the organization really needs. The Agile method embraces changes that add value, and reduces the cost of change through iterative development. Making changes to a small module is very cost-effective, compared to designing and developing a huge system and then trying to make changes to it.

Can Agile Project Management Work?

“At its heart, project management, whether you are doing traditional or Agile has very similar principles. It’s about doing a good job for the customer. It’s about leading a team. It’s about delivering measurable business results,” says Augustine. Many of these principles or practices can be implemented into most team-structured environments. Yet, some project management professionals may discard the principles of Agile management if they are unable to adopt all of the components and practices. This is a mistake. For example, what happens if they cannot get the user to sit full-time with the team in the workroom? It doesn’t mean they can’t incorporate



some of the other pieces of Agile management such as visual control and feature-driven development. Besides, even if a user cannot be involved on a full-time basis, most users are willing to participate on the team, especially during the testing and feature prioritization. The rest of the time, the business analyst can represent the user while the full-time core team continues to work together.

Incorporating Agile management techniques into projects fosters a focus on the benefits of each feature. In traditional project management, the teams strive to finish the project on time and under budget and often lose sight of the overall benefits the entire effort is intended to bring the organization. It’s important to remember the strategy the project is expected to advance as well as the total cost of ownership and not just the project costs. In this way, the benefits of the project will be obvious, whether the team is constructing a building or developing a new business solution.

Refernces

[1] New York Times, 11 July 2002 “Cost overruns (totaling hundreds of billions of dollars) for large public works projects have stayed largely constant for most the last century.”

[2] Ambler, Scott W. Agile Analysis.

[3] Agile Manifesto. Accessed April, 2007

About the Author

Kathleen B. Hass, PMP is Senior Practice Consultant for Project Management and Business Analysis, and Director at Large and Chapter Governance Committee chair for the International Institute of Business Analysis. She is the author of Managing Complex Projects: A New Model (Management Concepts, October 2008). Since 1973, Management Concepts, headquartered in Vienna, VA, has been a global provider of training, consulting and publications in leadership and management development. Management Concepts is a Gold International Sponsor and an IIBA Endorsed Education Provider For more information, visit www.managementconcepts.comor call 703 790-9595.

Agile


How to ScrumHow to bring scrum stakeholders, product owners and teams together to produce better backlog, release and sprint results.

Scrum is about Teams producing complex Results in an agile way. Scrum Teams achieve results by using a simple framework and set of rules. We will describe scrum to set the stage for an applied approach to scrum.

The Team

The fundamental element of scrum is the Scrum Team (or “Team”), which is a small (usually fewer than ten) group of Team Members who provide useful Results/Products for Stakeholders.

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

While the Stakeholders are the most important source of validation for the project, the most important person on the Scrum Team is the Product Owner (PO). The Product Owner works with the Stakeholders, represents their interests to the Team, and is the sole Team Member held accountable for the product the Team builds. The Product Owner must find a result that will satisfy the Stakeholders needs and desires. The Product Owner provides direction and goals for the Team, and prioritizes what will be done. The Product Owner connects the team with the purpose.

The Scrum Team Members are the people that actually do the work that satisfies the goals and priorities the Product Owner has set for them. Each Team Member is accountable to the

How to Scrum


rest of the Team for his/her performance, even as the Product Owner is accountable to the Stakeholders for the Team’s performance. The Scrum Team is cross-functional; that is, people on the Team (collectively) have all the skills necessary to do the work (analysis, design, code, test, documentation, marketing plan, drawings whatever is required for the desired outcome). The Team is self-organizing, self-managing, and constantly trying to improve itself. The Team works on the priorities the Product Owner has set, and the Team commits to the amount of work it can do without undue influence from the Product Owner.

In order to aid the Team in doing its work, there is a role on the Team called the Scrum Master (SM). The SM’s responsibilities are to be a facilitator, moderator and coach, with particular emphases on helping the Team mature its self-organization and self-management. The Scrum Master manages the relationship between the Product Owner and the rest of the Team, and facilitates removal of impediments for the Team – often working with the Product Owner, the Business Owner, and other Stakeholders to do so. Impediments can come from within the team and outside the team. The Scrum Master understands the scrum process and how the Team is using it, recommends process improvements, and assures that the Team is following the process they have agreed to.

The Backlog

A Scrum Team’s work is managed with a Product Backlog (“Backlog”), which is a prioritized list of Product Backlog Items (“PBIs”, “Backlog Items”, or simply “Items”). When the list is small it is just a simple list of things, as it grows we add grouping mechanisms to organize it and help us keep track. The list of work items can evolve from a simple “cut the grass” to demanding “build a 20 story interactive office building”. The key is that the list of work items evolves and becomes no more complicated than is necessary.

Agile


These Items represent the Stakeholder’s needs and wants – each of them is a request for something of value to be provided by the Scrum Team. These requests can be for anything, including software functionality, marketing, non-functional requirements, technical and infrastructure requests, business support, maintenance of existing systems, and so on. It is a rule of scrum that the Team shouldn’t do anything for any Stakeholder unless it’s on the Backlog. The Team will be actively working on the top few items of the Backlog during the Sprint; this part of the Backlog is called the Sprint Backlog, which is often thought of as a separate list of its own. The Product Owner is responsible for prioritizing that backlog and the Team is responsible for committing to as many Items they can do in a Sprint – thus creating the Sprint Backlog. From the Team’s view, the Product Backlog is work that we might do some day and the Sprint Backlog is work we are committed to doing.

The Backlog contains Items at all levels of fidelity, from vague wishes/wants/needs to finely detailed requirements. The higher the priority of the Item, the more detailed the request should be, so that it will be ready for planning and execution. Note: ready does not imply excessive detail but, instead refers to enough detail. The team working with the PO will determine what “enough detail” is. The key here is an unfolding dialog.

When a Scrum Project starts, the Product Owner should initiate the Backlog by working with the Stakeholders and other Team Members and capturing their needs, wants, and requirements as Backlog Items. As the Project progresses, the Product Owner and the Scrum Team should continuously work with the Stakeholders to (re)prioritize the Backlog, identify new Backlog Items, eliminate noise, refine and generally clean the items list to get it ready for planning. The project effort will result in product that will often clarify and identify backlog items. This process is called Backlog Grooming, and is a continuous process throughout the Project.

Now that we have the notion of the Backlog to work with, let’s describe the process, which involves discussion of both Releases and Sprints.

The Release

The Goal of a Scrum Team working on a software project1 is to produce and release results that meet the goals and priorities that have been set down by the Product Owner (hopefully as a result of working with Stakeholders).

Typically, before a project formally begins2, there is a Visioning phase, when the Business Owner, Product Owner, and the Stakeholders produce a Product Vision and a Product Roadmap. The Vision provides the overall focus for the Project, while the Roadmap gives guidance about Releases and their Goals.

The Scrum Team’s purpose is to create a result that satisfies the Stakeholders needs, wants and desires, often so that more demand for their services is generated. This production is done through a series of relatively short, fixed-length iterations, called sprints, in which results are

How to Scrum


produced by working on Items. The steps of a release are relatively simple, and I’ll describe them here.

Usually, the first thing that happens in a release is Release Planning. The Stakeholders, the Product Owner, and possibly other members of the Team, get together and negotiate what will be accomplished in the Release. This negotiation takes the Product Vision and Roadmap into account, balances the needs and wants of the Stakeholders against the abilities of the Scrum Team, and the result is a set of Release Goals and a Release Strategy to achieve them. The Product Owner and Team must update the Backlog so that there are prioritized Items on the Backlog that support the Release Goals and Strategy and are ready for planning.

Once we have a Backlog that supports the Release Goals and Strategy, the team starts Sprinting. The idea is for the team to do as many Sprints as the Release Strategy calls for, and then Release the Results. Each Sprint looks basically the same, with the Release activities as part of the last one.

The Sprint

The fundamental process flow of scrum is the Sprint, which is a relatively short period of time in which Backlog Items are converted into Results. The sprint is a regular rhythm of deliver for the team and seeks validation for the product from outside the team. The sprint is an opportunity to adjust.

The first thing to do in a Sprint

Agile


is Sprint Planning. In Sprint Planning the Product Owner works with the Team to negotiate what Backlog Items the Team will commit to for the Sprint in order to support the Release Goals and Strategy. Each of these Items has an agreed-upon definition of “Done”, and collectively these Items are called the Team’s Sprint Backlog. It is the Scum Master’s responsibility to assure that the Team commits to a realistic amount of work, and that the Product Owner does not unduly influence this commitment. Often, the Items on the Sprint Backlog are tasked out in order to give the team confidence that it can do the Item, and thus commit to it. The tasking of items can help the team mature by paying attention to the work agreements they make with each other. The tasking can also help the SM detect when the team is working well.

Once Sprint Planning is over, the team begins work in the Sprint. The team self-organizes to do the work and self-manages as it does the work. The Teams work pattern is described as a swarm to get the job done. Team swarm is a pattern of performing teams but, to an observer it looks like a swarm. While the Sprint is in progress the Team will have Daily Meetings in order that each team member understands what the Team’s status is. A daily standup meeting is for the team to orient their day and focus on a combined effort. This allows the Team to detect when to adjust in order to be as effective and efficient as possible. These adjustments often take significant time and occur after the daily standup.

During the Daily Meeting, and continuously throughout the day, the Team Members notify the Scrum Master of any impediments they encounter. It is the Scrum Master’s responsibility to facilitate the removal of these impediments. Often, this requires working with Team Members, the PO, the Business Owner, and other Stakeholders.

The Scrum Master must also ensure that the team does enough Backlog Grooming in order to be prepared for the next Sprint’s planning meeting. The backlog grooming is a strategy to prepare enough work to start on next so that a rhythmic flow of work can happen.

When the Sprint is over there is a Sprint Review, when the Product Owner and the Team show the team’s Results to their Stakeholders. This is done for two reasons: to prove to the Stakeholders that the Team is moving in the right direction, and so that the Team can get feedback on what they’ve done. If necessary, the Release Goals, Release Strategy, and Backlog are updated as part of the Review (or soon thereafter), taking into account the review and any “business reality” changes the Stakeholders may have. When teams are small we can rely on more intuitive reasoning to determine what the “right direction” is. As we grow we will see a need for more sophisticated techniques that use metrics to help us us answer what the “right direction” is.

After the Sprint Review, the Team has an internal retrospective to analyze its performance and process. The team decides what changes, if any, they wish to make to their process as a result of this analysis. These changes will be “enforced” by the Scrum Master in future Sprints. To enforce something the SM will need to shift the attention to the issue at hand. Energy follows attention, let the team react. Telling the team what to do is not desirable. Shifting the team focus and

How to Scrum


thereby enforcing change is an art of the SM.

At this point the Sprint is complete, and the team either begins the next Sprint, the next Release, the next Project, or disbands, as appropriate.

Quick Summary

� Team 7±2 does the work

� PO provides the work requests

� SM provides care for the whole team (PO/Team)

� Team swarms on the work

� Team is cross functional

� Team owns its process

� PO provides validation for each work request

� Work is done in short bursts < 30 days each (Sprints)

� Work starts and stops with Planning and Review

� Review demo for product; Review retro for process

� Daily standup detects any adjustments needed

� PO determines priority as a flow of work requests

� SM observes and helps the whole team adjust

� SM tunes the whole team for maximum performance

References

1. Maintenance Teams can also use scrum, but their scrum usually only contains Sprints, and not Releases.

2. The Visioning Phase can also be the first phase of a project, it can go either way.

About the Authors

Dan Rawsthorne has worked in software for more than 25 years in many capacities, from coder to product/project manager. He has worked small (3 people working on an e-commerce web site) and large (500 people working on aircraft avionics) projects, and has learned many things about what works and what doesn’t. He has worked in small “hack it out” companies and big CMM and ISO organizations and has been involved in process improvement in most of them.

Dan is a transformation agent who helps organizations change themselves through application

http://drdansplace.com/

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

http://www.scrumalliance.org/profiles/28-dan-rawsthorne-phd

http://doug-shimp.net/

http://www.scrumalliance.org/profiles/29-douglas-e-shimp

Agile Transformation Guidelines: Avoiding Pitfalls


Agile Transformation Guidelines: Avoiding PitfallsAsk the right questions and follow these key steps to transform to Agile painlessly. Learn how to revolutionize your development practices from an experienced Agile transformation coach.

Being an Agile transformation coach since 2001 at IBM and other companies has taught me a lot about being agile; especially the art of change. Increasing a corporate agile community from 300 to over 3,400, teaching two day courses to over 1,050 people, and consulting with teams were not the only ways I discovered the essence of “being” agile. Leading and coding with my agile team was just as wonderfully painful and educational.

Here is an eight point checklist that will help you save time and avoid common pitfalls in agile transformation.

� Be Type Aware

� One’s a Maverick, Two’s a Team

� Get Executive Cover

� Expect the Change Curve

� Lead with Pain

� Tool Up

� Create visibility

� Don’t Dictate – Facilitate

Be Type Aware

The Myers-Briggs Type Indicator (MBTI™) is used to help individuals understand their preferred ways of working, and to help teams appreciate diverse viewpoints. It lets people discover their most comfortable ways of working. For example, some people refresh your energy by being with other people, and others prefer to read a book alone. Some learn about their environment through models, and some with data. Some decide issues based on impact to people, and some prefer more detached logic. And some prefer spontaneous adaptation versus well laid out plans. Unnecessary friction can develop on the team without appreciation that people may differ not just in technical skill, but also in temperament and working style. This is especially true during the stress of process change. Educating the team in the different styles of workers up front and respecting the differences will side step this pitfall. MBTI™ has served many teams well, but other

Agile


similar tools are available.

One’s a Maverick, Two is a Team

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

Get Executive Cover

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

Expect the Change Curve

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

Lead with Pain

Instead of announcing the team will be doing a new practice, star by discussion the pain points that make the practices useful. For example, say “We seem to lose a lot when people leave the team”. This may highlight the need for pair programming with rotating combinations. “Sometimes people don’t like what we’ve built, even after careful specification”. The practice of using feedback from iteration demos will become attractive. Showing the problem and need, then bridging to selected approaches eases the team’s changes.

Tool Up

Spreadsheets and index cards are useful for learning agile concepts and are easy to work with, but using a tool designed for agile project management like VersionOne, RallyDev, or AgileZen helps guide new teams through the process. Moreover, it shows skeptics that there is a long history of industry investment. Introduction of tools specifically designed for an agile process is usually a pivotal moment of change.



Create Visibility:

Agile shines when the whole team can understand the flow of work, and pitch in to help or identify problems. Your selected agile project management tool can help, and physical artifacts can supplement these. You’ve succeeded if team members know not just the status of their work, but have an idea of the workflow of the team as well. Artifacts for this can include Scrum’s burn down chart, the taskboard or Kanban board, build and test success lights for continuous integration

Don’t dictate – Facilitate

There are variety of good assessment surveys for your teams retrospectives or lessons learned, such as the Shodan Adherence Survey [2], the Agile Evaluation Framework, [3], Comparative Agility(tm) Assessment [4], and the Sidky Agile Measurement Index (SAMI) [5], IBM Rational Self Check for Software Teams [6], and Dean Leffingwell’s Agile Process Metrics [7]. They rate questions numerically to view the team’s deployment level of given practices. This gives people a head start on a solid combination of practices.

But counter intuitively, there is also a niche for placing the work of authoring questions, targeting towards measuring their progress with “being” agile on the team members. This engages another section of their brain. They can bring their unique perspective on observed problems, and key practices into the instrument. Numerical assessments of teams can rotate between a repeated standard list of questions, one of several alternate sets for variety, non numeric retrospective techniques as described by Derby and Larsen in “Agile Retrospectives” [8]. Try also adding a session for an iteration’s retrospective where the team constructs six questions. The act of choosing the top 6 and wording the questions can be a key learning moment. The coach can cue the team by suggesting they consider practices in the following key areas: requirements analysis, workflow management, building quality, and process optimization. Within that framework, people should engage their experience to choose fresh questions. The exercise of considering these can be as valuable as the questions and data themselves.

This approach gives you the best benefits of each technique. You get historical trend data, variety to explore fresh questions on alternate iterations, non numeric methods, expert thought using pre-crafted questions and best of all, team buy in and enthusiasm for the questions they have developed. Learning from the experts is good, but sparking the learner’s analysis of what they would ask is equally powerful.

The coach’s role is to help the team create their questions. The coach can guide the team in considering some key areas, such as what practices they feel are key for quality, or what practices they feel are key for requirements. The coach can also warn the team of known pitfalls in terms of which wordings or practices may not work. But the coach also needs to be open minded. The goal is not to lead the team to a particular answer, but to enable the team’s creation of a question

Agile


set that works for them in use, and teaches them in the process of its creation.

This example shows questions that were developed not by a consultant, but by a team beginning their agile journey. Having them write the questions serves as a great way for coaches to glean the team understands the core principles. Longer consultant generated surveys are still fine, but these team generated ones give you a view of what’s inside the mind of the team.

Practice Explanation LevelScrum Meetings Do you hold short daily planning meetings that highlight

what each person did yesterday, today, and blockers?

Prioritization Does your team continuously review the business value of your requirements?

Velocity Does your team observe their actual rate of progress, and update their plans?

Estimating Does your team provide estimates focused on relative size and complexity?

Communication Does your team communicate with the right people at the right time, and show visible progress of the project?

References

� Virginia Satir. Satir Change Model. http://www.satirworkshops.com/files/satirchangemodel.pdf

� William Krebs. “Turning the Knobs: A Coaching Pattern for XP through Agile Metrics”. Springer, 2002

� Laurie Williams, William Krebs, Lucas Layman, and Annie I. Anton, “Toward a Framework for Evaluating Extreme Programming,” Proceedings of the 8th International Conference on Empirical Assessment in Software Engineering (EASE ‘04), Edinburgh, Scotland, May 24-25, 2004, pp. 11-20.

� Mike Cohn. “Succeeding with Agile”. Addison-Wesley, 2009. Also online at comparitiveagility.com by Mike Cohn and Kenny Rubin.

� Ahmed Sidky and James Arthur. “A Disciplined Approach to Adopting Agile Practices: The Agile Adoption Framework”. Agile journal, June 2007. Also see “Becoming Agile” by Greg Smith and Ahmed Sidky. Manning 2009

� Per Kroll, William Krebs. “Introducing IBM Rational Self Check for Software Teams”. developerWorks ®

� Dean Leffingwell. “Scaling Software Agility” Addisson-Wesley 2007.

� Ester Derby and Diana Larsen. “Agile Retrospectives”. The Pragmatic Programmers, 2006.



MBTI is a trademark of the Myers-Briggs Type Indicator Trust

IBM is a trademark of the IBM Corporation.

developerWorks is a Trademark of the IBM Corporation.

Learn more: see VersionOne.com, Rallydev.com, and AgileZen.com for more details the tools mentioned.

About the Author

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

http://www.versionone.com

http://www.rallydev.com

http://www.agilezen.com

http://www.meetup.com/agile3d

http://www.meetup.com/agile3d

Agile


Managing Customer Expectations in IT Outsourcing

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

In today’s market, customer expectations are frequently discussed. Everyone talks about them, and everyone claims their company takes care of them. The awareness is evident, but there are many customer expectation misunderstandings due to:

� No formal, defined process for customer expectations management (CEM)

� No industry standards or best practices defined for CEM

� No classification for unique customer expectation sub-topics (CRM, issue/feedback tracking, partnership development, CSAT, customer service, etc.)

� No customer expectations management specialization, (e.g. CEM for IT service providers, CEM for manufacturers, etc.)

Although each industry has its own unique challenges, there are some general rules you can follow for successful customer expectation management. First let’s define expectation.

What Are Customer Expectations?

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

1. A primary measure of success

2. Drive all of your client’s actions and decisions

Typically, your customers are satisfied when you come very close to their expectations. This can apply to both processes and results. In fact, customers will have expectations about both, and expectations have different sources.

Key Customer Expectation Sources



Personal and Company Needs

People differ in their needs and motives. What is important for one is irrelevant for the other. For example, for some clients it is very important to be constantly informed by the project manager (PM) about status changes, while others will find this unimportant.

Previous Experience

First-time car buyers may have only one expectation – the car will drive. Over time, however, those expectations grow into new expectations regarding comfort, security and many other things. With experience, customer demands for professional competency and its value grow.

References

Personal references or referrals about products/services unfamiliar to the customer are important. Buyers are influenced by those they know, as well as strangers.

Promises made by the company

Many feature, pricing, service level and support promises are made during marketing campaigns and pre-sales phases. Numerous expectations are formed during these times. Messaging in advertisements and web-site/internet resources can also influence what clients expect of you.

Expectations Can Take Different Forms

Desired Level

Expectations need to conform to initial clients wishes. The desired level depends on the client’s background. For example, the expectations of a person who lives in a castle differ from the expectations of a person who lives in a flat. It’s important to know that cultural differences and expectations play a significant role when outsourcing to foreign countries.

Ideal Level

Clients are most satisfied when their expectations hit an ideal level where an acceptable price is matched with the highest level of service. The notion of “best service,” however, is unique to each individual customer.

Typical Level

A typical or common level of service is understood when the product or service is well known. For example, people know exactly what to expect when they order “fast food.”

Agile


Minimum Acceptable Level

Minimum service level expectations are often linked to price. For example, a clean bed might be a minimal expectation for a low-priced hotel room. The customer might forgo the TV and mini-bar in order to save money.

You need to understand client expectations in order to meet desired service levels. At the same time, expectations are dynamic and may change over the time. Things change as collaboration progresses and specific situations change (what was ideal yesterday, might not be acceptable today).

Expectations Come From Different Sources

In the software development business, the typical customer is usually a company looking for an outsourcing vendor/partner. It’s not a specific individual who has expectations that need to be managed in order to succeed. The “company” is a stakeholder list with a hierarchical structure and internal corporate politics that need to be taken into account. For example, project manager expectations differ from CIO and CEO expectations. People within the company have different levels of influence that also need to be considered. It would be nice if all the customer stakeholder expectations were the same, but that’s not the case. Your job is to examine discrepancies and figure out if there’s a way to make everyone happy. Alternately, you can determine which individual expectations are most important to your project’s success.

This is why we recommend the following ongoing CEM framework:

Customer Expectations Management Process

Analyze

Identify your stakeholders from the customer side. List all the contacts you have and those you want to acquire in future. List all the positions, based on the customer’s organization chart, of your stakeholders and assign roles and influences. Identify your champions and those that oppose you and understand their motives.

When you begin negotiations with your new customer, it’s easy to obtain detailed information. At this stage, people are very open to expressing their expectations. The only thing you need to do is ask. The service provider may identify contradictory expectations from different stakeholders and these should be prioritized and examined closely.

Set

After you’ve analyzed and clarified customer’s expectations, it’s time to align them with yours by setting expectations for the services you will provide. You need to build the right management



hierarchy, and escalation and communication schemes to reflect the client’s management. In addition, the project manager should align the team structure and team work, prioritizing expected result areas and building the right Software Development Lifecycle (SDLC) processes. When dealing with offshore outsourcing, you’ll need to identify cultural differences and provide special training to better align teams and collaboration expectations.

All these critical steps and actions should be covered early on – during a stabilization and collaboration phase. It’s best to take care of these requirements before the actual project starts.

Manage

When the project starts, you’ll need to manage expectations dynamically, because they will change as the project moves from one stage to another. As you achieve results and pass project milestones, you need to periodically check expectations and synchronize new developments with new expected results and actions.

…And Analyze Again

At some point you’ll need to analyze expectations again. You may have several triggers that re-initiate the ANALYZE phase such as:

� Organizational changes on either side of the table

� Stakeholder lists may change

� Completed milestones might trigger new analysis (i.e., contract re-negotiations, new service releases, new opportunities, new product lines, etc.)

Conclusion

Good customer expectation management requires your commitment. This is a process that needs ownership. You have to identify the person(s) within your that company should analyze, set and manage expectations. This could be same person who builds the partnership with the client (i.e., client partner, project manager, etc.). They may track expectations as additional items within CRM systems, project plans, risk management plans or any other document/tool that is actively used and maintained. You could also organize a team that manages all expectations within the company (audit or consulting teams).

Keep in mind that customer expectations are continuously evolving. Improvements and re-alignments will lead to a higher quality of customer service. Improvement should be tracked by cutting-edge methodologies, better SDLC processes, industry certification standards and most of all specific customer feedback. Remember that your most unsatisfied customers are the most valuable source for improvements. They help you and your organization grow professionally and they help you exceed customer expectations in the future.

Agile


About the Authors

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

Outsourcing is Not a Slam Dunk


Outsourcing is Not a Slam DunkOutsourcing requires explicit documentation and communication methods. Learn how to plan outsourcing projects, select the right partner, and govern the relationship.

Outsourcing Overview

In today’s business climate, companies are looking to other parts of the world to leverage talent, infrastructure, innovation, and agility – in addition to more attractive personnel costs. After all, technology has enabled this globalization, and further, technology has helped to erase any sense of geographic distance among both people and industry. In fact, the practice of outsourcing has infiltrated every facet of business, and some of the largest

companies in the world rely on outsourced partners to deliver complex and critical services and products for customers and the companies themselves. While many businesses have been able to reap the rewards of outsourcing, other companies have experienced the heartache and disappointment of outsourced projects that have ended poorly.

While outsourcing may be the answer to many organizational challenges, outsourcing is not – by all means – a sure-fire solution. Outsourcing is a venture that cannot be taken lightly as it requires investigation, diligence, governance and refinement. Outsourcing involves a commitment, not only in the initial stages, but through the entire lifecycle. Thus, in order for outsourcing to succeed, a company must have a clear plan, select the right partner, and govern the relationship with very explicit documentation and communication. When executed properly, outsourcing can generate tremendous success on a number of levels, and it can most certainly allow businesses to extend capabilities and profit.

That said, at a high level, outsourcing poses a challenging predicament. Outsourcing requires an organization to select a company from a sea of many unfamiliar vendors, and to entrust the chosen company with processes or products that may be critical to that particular business. The outsource partner may be continents away, may never be seen face to face, and may not even share a common language with your organization. Also, to complicate matters, your outsource partner may know nothing of your business or of the clients the outsourcing company is proposing to help serve. As a whole, this situation can make for a very tenuous arrangement that can be steeped in anxiety and uncertainty. The key to success with outsourcing then is to overcome these gaps and build a foundation of understanding and explicit expectation.

Agile


Establishing a clear objective that outsourcing will serve for your business is a great beginning to this process.

The Drivers of Outsourcing

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

Agility and Efficiency

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

A lack of internal skills or infrastructure

Most companies are continuously seeking new sources of business and revenue, which means new opportunities are very rarely ignored, even if these opportunities may fall outside the core competencies of the organization. After all, if a business cannot meet a need in the market, a competitor will identify a way to meet this need, and leave the pack behind. In order to keep up with the competition, businesses must continuously evolve through ongoing research, development, learning and growth. This cycle can be very expensive, and when the skills and infrastructure a company requires exist within another organization, a case for outsourcing exists. Leveraging the experience and skills of an external company without having to invest in learning or the development of new infrastructure is a major driver of outsourcing.

Costs

The overhead associated in keeping a business running can often make providing specific services and products cost-prohibitive. This situation can be particularly true in unstable and changing markets that push prices beyond what the market is able to bear. Reduced labour or material costs in other geographic locations, however, can allow a company to continue to provide the same services and products – more effectively – at a competitive rate. Note: Outsourced projects typically require an increased allocation of internal Project Management time. Therefore, you should factor these costs into the budget of any outsourced project.



Business development opportunities

Forging relationships with companies that can support your business can also result in opportunities to reciprocate referred business. If your outsource partner is located in a different part of the world, that company may be able to introduce you to an entirely new market – along with a complete new set of clients. Explore the possibilities that exist and talk to your partner about how you can help each other grow your respective businesses.

Thus, there are many compelling reasons why outsourcing may be the right solution for an organization. However, your organization should not pursue outsourcing blindly. Understanding why outsourcing can be the right choice for your company will help to reinforce your outsourcing decision when challenges may arise. That said, you should have conviction in your outsource model – and remember that commitment is paramount to long-term gains.

How To Get Started

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

Write a good RFP

Good outsourcing is rooted in clear communication, and your first touch point with a prospective vendor should be a request for proposal. This document is an opportunity to demonstrate business savvy, and to set the bar for quality, professionalism, and protocol. Sadly, I cannot count how many RFPs I have read cover to cover – only to wonder what the party is actually seeking! Thus, remember to be as clear as possible about what you expect from your vendor. The RFP process should not be a game of decryption – testing respondents on their ability to comprehend a convoluted document. You should use language that is appropriate to the services you are seeking. Be explicit and thorough. If you are issuing the RFP internationally or overseas, identify the language skills you expect your vendor to possess – as well as the response times and time zones the vendor must work to service.

Do your research

The international market is flooded with companies claiming to have capabilities in every aspect of business outsourcing. While these claims may not be made with malicious intent, realize that many companies are hungry to get a piece of the pie, and will overstate experience and skill-set to win your business. Ask for examples of their work, speak to some of their other clients,

Agile


and always request a detailed breakdown of their own workflow process and contact strategy. Remember to ask questions such as how does the company ensure quality? What infrastructure exists within their organization to ensure connectivity, up-time, security and reliability? Who do they employ, what are their on-staff skills, and what are their contingency plans for employee attrition? How often will the company communicate with you and what documentation can you expect to track their work? What is the time difference – and who will respond to after-hours emergencies? If they cannot immediately respond to these questions, consider that the company may not have the experience needed to uphold a successful outsource arrangement with an overseas client.

Consider the differences among international talent

Professionals who are experienced working with outsource partners speak to the variances in work style and competencies based on location. Comparing India to Ukraine, for example, reveals some fundamental differences in outsourcing experiences. For instance, Elizabeth Cooper, the CEO and founder of Intelligent Pipeline Inspection Gauge (iPIG LLC), a California-based dedicated service for the oil and gas industry, needed help with technical aspects of her work. Specifically, she needed help debugging the highly technical software that analyzes the risks of oil pipelines and vessels, and in making improvements to this software’s overly technical interface. Working with Ukraine-based SoftServe, she found the high level of mathematical expertise of these programmers invaluable.

“The ability to deal with highly computational software with long derivative algorithms was essential to the project’s success,” says Cooper. “The Ukrainian developers we worked with had true mathematical expertise, not just with software. This enabled them to demonstrate after they debugged the software they had left the mathematical algorithms intact. We couldn’t have done it otherwise.”

Wade Person, the Director of Software Development at a Fortune 500 company, also noticed the differences of working with outsourcing companies in different countries:

“My experience with the Indian companies I worked with was that they would always do exactly what you wanted them to do, no more, no less. What I really appreciated about SoftServe, the Ukrainian company I worked with was their level of involvement, sense of ownership, and willingness to make suggestions. We would give them directions on how to do a certain feature and they would sometimes come up with a better way to do it. They were always very open and tactful. With the Ukrainian company I felt that we were much more on the same wavelength.”

Selecting the right partner is a key factor in outsourcing success; consequently, the process should not be rushed. Always remember that outsourcing is about long-term value. Thus, you should look for a company that you like, and that could grow with your needs over time.



Staying On Track

Governance and relationship management are fundamental essentials if any success is to be had from a long-term outsourcing arrangement. As is customary with internal staff, your extended (outsourced) staff must be evaluated and monitored for consistent performance. In fact, this situation becomes even more important with a team that is geographically distant. To achieve a true partnership, however, an organization should never manage an outsource vendor harshly. The quality of the relationship will affect the outcome of the work a partner produces. The partner must feel integral to the business – and not like hired help whose efforts can be replaceable at the slightest hiccup. You should also cultivate trust through professionalism – in other words, you should treat your overseas partner the way you would treat a local associate. That said, you should also have solid agreements in place to rely on if the arrangement turns sour.

Demand a thorough service level agreement

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

Give your outsource team context

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

Recognize the need for strong Project Management

Regardless of what other recommendations you choose to follow, dedicating a Project Manager to govern the day-to-day relationship is the single most imperative rule of successful outsourcing. The Project Manager will craft detailed project specifications, develop a strong relationship with your partner, and will monitor progress closely enough so that potential challenges can be

Agile


identified and resolved before having any major impact. As the geographic distance can make outsourcing very challenging to the service provider, a dedicated point of contact that the service provider can communicate with when needed is extremely helpful – and will only reinforce a sense of teamwork and foster commitment to your business.

Make quality the end goal for all

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

Establish a contact strategy

Be explicit about how often will you speak with your vendor. Identify what days you will communicate, and what the purpose of each exchange will be. Do not let the project get away from you. Stay in close contact with your vendor – participate in the project and everyone will feel more of a responsibility to one another.

Commit to it

One of the classic fatal errors any organization can make is not fully committing to a project. Own it – understand it – and stay on top of it. If you do not have the time or know-how, hire a reputable, specialized outsource management group. These groups exist to help select an appropriate vendor, or to manage the outsource process to a vendor the group will be responsible for. Make sure that they have the experience and that the group will stand behind the work of the vendor the group chooses to conduct business with.

Learn from it

Whether the project was a smashing success, or an unfortunate failure, consider why the situation occurred. Discuss the project with your vendor and your colleagues to determine if you would change anything during future dealings. Ideally, you should conduct a post-mortem – where all of the involved parties are given an opportunity to discuss the project frankly. Document the changes you agree to make, and ensure that the Project Manager incorporates the revisions to the process in any future projects.

Understanding The Risks

While outsourcing can obviously provide many benefits, this method does not come without risk.



Outsourcing has created a modern-day gold rush, where every company, big and small, is looking for ways to cash in. Being aware of what can go wrong is critical to ensuring that the outsourcing model is well-developed and that the risks are minimized.

Lost IP

Over time, your outsourced team will come to learn the facets of your business intimately – perhaps even at a deeper level than your internal employees. This relationship is a natural side-effect of outsourcing, but it is important that any new intellectual property that is captured by the outsource partner will be transferred back to the organization. How this knowledge sharing takes place largely depends on the type of work that is being conducted, but written reports and ongoing status updates are two effective ways of ensuring that knowledge is documented by the outsource partner.

Poor quality

A lack of quality is probably the most-reported issue when it comes to outsourcing. The problem may occur because of varying standards, a lack of clarity regarding what was expected, and sometimes, an incompetent vendor. For all these reasons, a thorough review of progress must be conducted very soon after engaging with an outsourced partner. Do not allow a significant amount of time to pass before requesting to see the end product. Get your vendor accustomed to these check-ins, do the check-ins frequently, and do them consistently. If issues with quality arise, work with your vendor to determine an appropriate solution. Engaging the extended team in making improvements will shift responsibility for better work to the outsourced team.

Unexpected surge in internal Project Management time

Outsourcing projects requires more Project Management time than if the work was completed internally. Remote teams require more communication and status reporting; thus, the Project Management role will see an increased allocation of time spent on outsourced projects. Ensure that the bandwidth exists internally to manage such projects, and budget for these projects accordingly. A good rule of thumb is to allocate an additional five to ten percent Project Management time over what is typically budgeted for internally-executed projects.

Overall then, geography should not limit the potential of your business. International talent offers alternative means to deliver products and services –- rapidly and cost effectively – without compromising quality. In the current economy, outsourcing is not only viable; it is often needed to maintain a competitive edge. If you have not yet tried outsourcing, expect a steep learning curve for the initial six months. As with any other new business practice, learning how to navigate unfamiliar territory can be intimidating and very challenging. Outsourcing is a strategy that can bring long-term gain; consequently maintaining a commitment over time will see your company overcoming many initial issues and enjoying the ever expanding opportunities on the horizon.

Agile


About the Author

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

http://ginalijoi.blogspot.com/

Software Development Outsourcing: Get Control of Cultural Differences


Software Development Outsourcing: Get Control of Cultural DifferencesIlluminating the differences between cultural mindsets helps companies improve the success of their software development outsourcing strategies.

Introduction

Outsourcing IT and software development is becoming commonplace. After all, there are numerous advantages including lower costs, additional expert resources, faster product development, faster time to market, and flexible human resource allocation.

However, there are unobvious differences in work methods and habits due to varied cultural ways of perceiving and relating to

events and people. Accommodating these differences can significantly influence the building of productive relationships and make outsourcing a smoother process. For example, China, India and the Philippines engage in a process-oriented culture wherein the main focus is on structured processes and well-defined instructions. Work proceeds comfortably in Waterfall and V-model processes. On the other hand, a more dynamic Eastern European culture is closer to Western tradition which tends to accept flexibility and pro-activeness using Agile methodologies and direct communication.

Why does this occur? And what are additional obstacles besides the obvious technical issues?

Barriers to Communication among Different Cultures

When a company decides to outsource work, it usually chooses to work with an organization of a different culture. ‘Culture’ is defined as a complex set of values, behaviors, and beliefs that are shared by a specific group of individuals. Each cultural group expresses authority, creativity, accountability and other values in different ways.

Here are some obvious common barriers to communication with other cultures:

� Language

� General Education Level

� Time Difference

� Nationality Specific Traits

Agile


� Religious Beliefs

� Gender Roles

� Individual Personal Space and Behavior

Culture specific differences influence collaborations in a huge way. The following paragraphs enumerate some common criteria to evaluate differences which are important to take into consideration when outsourcing offshore.

Low-Context and High-Context Cultures/Direct and Indirect Communication

Low-context and high-context means the manner by which communication occurs and the way information is presented.

Low-context: (e.g. Germanic, Scandinavian, and Anglo)

� Usually written out in a full, concise, direct manner with numerous dependencies.

� Focus is on specific money figures and deal closing.

� Can cause specification and reporting misunderstandings.

High-context: (e.g. Japanese, China, Indian, most Asian and French)

� Less information detail.

� More emphasis upon reputation.

� Confrontations are minimized.

� More value is placed on politeness than clarity.

High-context cultures may interpret low-context cultures as being aggressive, whereas low context cultures may perceive people from high context ones as being overly secretive.

Polychronic vs. Monochronic Cultures (multi-tasking abilities).

Polychronic:

� Tend to multi-task.

� Open-door policies.

� Take calls in meetings.

� Typical USA.

Monochronic:

Focus on one task at a time.

� Sense of orderliness.



� Not fond of interruption.

� Pride in a sense of orderliness.

� Typical German (e.g. may be offended that an American is taking a phone call while in a meeting).

Past, Present and Future Orientation Cultures

Past-oriented societies:

� Tend to be conservative.

� Relate to a more traditional way of doing things.

� Long historical traditions include Britain, China and Japan.

Present-oriented societies:

� Prefer short-term benefits

� See the future as an uncertain place.

� Past as past.

� Examples: Many Spanish-speaking - Latin American countries, Philippines, Sri Lanka.

Future-oriented societies:

� Emphasis and optimism on the future.

� Believe that they can have a positive effect on their future.

� Young nations and the United States are good examples of future-oriented societies.

Individualist vs. Collectivist Cultures

Individualist:

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

� Work generally assigned to one individual.

Collectivist:

� Work, comply, and identify well with groups that look after them. (Asian)

� Consensus is required.

� Tasks are generally assigned to group (usually takes longer).

Time Perception

Western cultures:

Agile


� Time is being used up and cannot be replaced.

� Time is money.’

� Punctuality and deadlines are valued.

Non-Western:

� Time is plentiful.

� Punctuality, deadlines not important.

High and Low Power Distance Societies

High power distance:

� Boss is always “right” (even when wrong)

� Asian and Russian

Low power distance:

� Both employees and managers on a more equal level

� United States and Northern Europe

Cultural Differences in the Software Development Process and Communication

With respect to software development, these cultural differences may cause problems among culturally dispersed team members. Those who don’t have this experience should closely collaborate on daily basis. For example, American software development companies approach time differently from a relationship-oriented culture such as India. Indian workers prefer to spend more time with the American workers in order to better know each other. Individuals from time-limited societies in turn do not take time to develop trust and relationships and instead rely on legal systems to handle these problems. In cultures where time is plentiful, like Latin America, Asia or India, making a person wait is common. An American team prefers to handle the tasks at hand quicker that their counterparts from India. As a result, both groups of people may gain negative impressions of each another – and this type of misinterpretation can hinder work down the line.

Other potential differences that cause misunderstandings during the software development process include a culture’s interpretation of hierarchy, deadlines, and product quality. Further, language barriers can result in misinterpretations and cause project delays. With respect to the actual software development product, cultural developments can surface as well. For example, one type of user interface may be acceptable in one culture but not another. Western result-oriented professional behavior can cause conflict in China’s process-orientated culture, where result is treated as a “death” and process itself as a “life”.



How to Minimize Problems Caused by Cultural Differences

Companies should consider the proper expectations from the start and be ready to confront differences with other cultures. Further, instead of being conflicted with these issues, companies should understand the root cause of these differences and work through these “bumps.” That said, there are ways to avoid or minimize problems caused by cultural differences.

To minimize problems, organizations should:

� Take part in intercultural training. Learning about the culture and mindset of the organization that you are working with can work wonders when it comes to improving the working relationship. Further, learning about the culture develops cultural empathy and the capability to solve potential intercultural problems.

� Work towards finding cultural common ground. By doing so, both cultures can build relationships and build upon the strengths of each culture as well.

� Let the IT manager responsible for the outsourcing project spend time in the outsource location. While analysts recommend that managers spend a month in the outsourced location in order to fully understand the cultural nuances of the place, a shorter length of time - even a week - can be helpful. Team building exercises are recommended during this stay.

� Interview individual team members to ensure that they will be suitable for your organization’s needs. Also, double-check that the people you interview are the team members who will actually be doing the work.

Additionally, ask for approval for future personnel changes.

� Address the issue of culture and previous outsourcing experience in the Request for Proposal (RFP) document. The culture of the outsource company that you may be working with should be adequately described.

� Ask the outsourcing vendor to engage employees in team building and general training activities on a regular basis. Some examples include learning about your organization’s culture and taking English classes.

� Train the outsourcing provider. Provide the vendor with information about your company culture so that the vendor will have a better understanding of your company’s values, communication methods, and other pertinent cultural information.

� Educate your employees. Provide information about the outsourcing vendor on your company website. Also, it is important to provide information about this vendor through a company email or newsletter.

� Find a way to improve both the communication and the collaboration between the different teams. A good way to achieve these particular goals is to have regular personal contact with each other and to engage in team meetings on a regular basis. Allowing team members to

Agile


freely engage in giving regular feedback is another effective strategy for encouraging clear and concise communication among all team members

� Set some ground rules. For instance, it is important to clarify at the beginning which party is responsible for the quality of the end product.

� Make sure that you clearly define what success is – and be sure to celebrate successful benchmarks so that enthusiasm will be built within the outsourced vendor.

� Determine who makes periodic reports and how often these reports are made. After all, these types of reports allow you to measure the progress of your project.

Conclusion

Understanding cultural differences within a software development context is extremely important to organizations from a productivity and monetary point of view because people matter more in our industry than elsewhere. To enjoy the great benefits outsourcing can give, you should take appropriate precautions to ensure that both your company and the outsourced partner overcome cultural barriers that may arise. If cultural differences are handled in an effective manner, the advantages gained from working with an outsourcing partner will be extremely beneficial to your organization – and to your bottom line in turn.

It’s up to you to decide which direction to go with outsourcing and which way to minimize such unobvious but important factors in globalization.

About the Authors

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

Yuliya Sorokhan is the BA Methodologist, BAO, at SoftServe (http://www.softserveinc.com), a leading global provider of proven high quality software development, testing and consulting services. Ms. Sorokhan has worked in the company since 2004, and was previously in the positions of Quality Assurance Manager and Partnership Program Manager. She holds Master’s Degree in Applied Linguistics from Lviv Polytechnic National University, Ukraine, and is currently finishing her PhD.

http://www.softserveinc.com

http://www.softserveinc.com



PROJECT MANAGEMENT

Project Management


Five Pillars of Practical Project ManagementThere are only five pillars of practices that make a project manager successful. Is it hard to believe? Read on to find out.

Really? With such a preponderance of project management literature it is hard to believe there are only five pillars of practices that a project manager has to engage in to maximize their potential for success. OK. What are they? I’ve got to see them.

The five steps include:

1. Project Planning

2. Project Baseline

3. Reporting

4. Change Control

5. Project Closure

That’s it. If project managers can do these five things, and the little things behind them, they will see great gains in project management performance and greatly enhance their ability to succeed. Sounds simple enough, but sometimes the simplest things are the hardest ones to accomplish.

Project Planning

Project managers need to stop over-complicating this initial phase. In its basic form, project planning focuses on identifying and documenting items related to a project’s scope, time, and cost. In short, it is the basic process of documenting the understanding each party holds related to the project.

Nothing else should be allowed to creep into this phase. The worst thing that happens at this stage is when project managers take a project plan and start adding little things to it. The project plan must be matched with the project’s size and complexity and tailored accordingly. It is not a one size fits all approach.

Project Baseline

The project baseline captures the project’s predicted scope, time, and costs at the very beginning stages, or anytime thereafter if someone chooses to change them. In other words, it’s a snap of

Five Pillars of Practical Project Management


the chalk line. Project teams must treat the baseline as sacred, and only modify it through the change control process as described below.

This is possibly one of the hardest things to get through to project managers, and once again culture is the culprit. If a company’s culture is one where people tear one another down when mistakes are made, then people are always going to hedge their bets. Nobody thinks what they’ve got is going to be good enough, and therefore they overestimate what can realistically be done. Project managers must become good at knowing when good enough is, well, good enough, and have the discipline to tow that line.

Reporting

Reports should be based on variances from the baseline in terms of time, cost, and scope, and they need to be metric-based to ensure people are collecting information on a regular basis. If metric-based reporting doesn’t occur, then managers won’t ever get the data they need because no driver or reason exists for collecting it.

Good reporting ensures all people are collecting important information on a regular basis, and keeps all project managers out of the fantasy world they so often like to inhabit. It keeps them anchored in reality. Most project managers don’t like to report on progress, and yet somehow they continue to believe (i.e., hope) they will magically improve anyway. Reporting provides a snapshot of where project managers and their projects really are at any given time, not where people wish them to be.

Change Control

The change control process is meant to protect sacred project baselines while helping to manage key expectations among project stakeholders. The very word ‘control’ implies that somehow the process is intended to stop something from happening. But while change control does need to be a strict process that treats the project baseline as holy, it does not need to be inflexible. This is an important distinction that eludes many practitioners, much to the detriment of project results.

The main goal of the change control process should be to get and keep everyone on the same page, foster discussion, and then realign expectations when necessary. Rather than emphasizing control per se, project teams should be placing more emphasis on collaboration. In other words, everyone needs to view projects with all three major criteria in mind – cost, scope, and time – as this is what leads to project success. If, for example, a change in time is requested, there will likely need to be some give and take in the other two areas to accommodate such a request. When project managers are able to see the big picture, they are much more willing to compromise on certain issues if it means realizing a greater overall result.

Project Management


Simply put, change should not be feared. However, stakeholders must understand that they can’t get something for nothing. Instead of prohibiting any adjustments, the change control process should foster the free exchange of ideas, negotiation, collaboration, and a realignment of expectations. It should not be a cold gaiting process or be characterized by one transaction. Rather, it requires multiple iterations, and often times relationships need to be nurtured. This approach serves to remove ambiguity in expectations, and is the only process by which the hallowed baseline should be changed.

Project Closure

When one project finishes there is always one or more needing to start-up, often already behind schedule. Project closure is often skipped because of this to the detriment of everyone involved. Without closure between projects work becomes this monotonous flow of never ending intensity. Closure is important intellectually and emotionally. There is no hiding when a stakeholder is asked to sign off on the projects. They either do it or continue the project. It forces finality. Lessons learned must then be collected to broaden the project team’s and the organization’s experiential base.

Finally, a get together to enjoy each other’s company, replay the good memories, laugh at the not so fun ones builds emotional bonds between project members and encourages us to move on and embrace future challenges.

Don’t underestimate the amount of effort it takes to master these five areas. They contain the bulk of project challenges and forgo the nice to know stuff. That’s why the five pillars are so important. They keep project management practical and reap efficient success as a result.

About the Author

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

http://www.systemation.com

Value Triple Constraint: How to Evaluate Project Value Delivered


Value Triple Constraint: How to Evaluate Project Value DeliveredHow to use VTC (Value Triple Constraint) to quantify project value delivered while understanding actual benefits and detailed ROI.

How do we measure project success? Do we measure budget and schedule or do we measure net value delivered to the organization? Today, we tend to measure the former. But it is the latter, delivered value, which is the truer measure. This is the way projects will be evaluated in the future. The current Triple Constraint focuses on the delivery portion of a project, rather than its business value. It focuses on a single project, and is primarily based on a cost view.

The Value Triple Constraint is an evolution of the Triple Constraint. It is a framework for measuring the on-going value delivered through projects and for bringing to light the “value left behind”. It is pictured below

The Value Triple Constraint states:

Value delivered is a function of the Scope of the business opportunity and of our Capability to identify, decide and deliver to the opportunity.

Exhibit 1 - Value Triple Constraint

Project Management


From a business perspective, a project is aimed at taking an organization from one level of measured performance to a higher level of measured performance. To determine if we have achieved that objective we need good methods of measurement.

The Value Triple Constraint: Tracking Four Distinct Phases

The Value Triple Constraint (VTC) tracks an opportunity through each of four distinct phases as follows, from last to first:

� Realization Phase. This is where we implement the output product or service and begin to harvest the results. Naturally, we want to deliver a positive value. In reality, this may be considered mostly outside the project, since it occurs after the project is complete.

� Delivery Phase. This is our current focus of attention. It consumes most of the effort, attention and costs of the project. It is the phase where we apply the classical triple constraint. However, the conditions for business success are largely set before this phase, outside the actual project. Also, while the project is being delivered, the eventual benefits are being delayed and so speed of delivery is important.

� Decision Phase. This is the phase where we select among the many to decide which projects will go forward and when. Although this phase doesn’t consume significant costs or effort, it does often consume significant calendar time. It focuses on cost-benefit, not value delivered.

� Identification Phase. This is not a phase with which many organizations are even familiar. There is a point at which we recognize that there is an opportunity. However, that opportunity may have existed for many months or many years. Just because we didn’t see it until now, doesn’t mean it didn’t exist.

We tend to focus on the delivery phase. That’s where our budget lives. The decision and identification phases contain very little budget costs. But they represent significant opportunity costs. However, opportunity costs don’t show up on any P& L statements. There are no statements that present us with value that did not show up. The Value Triple ConstraintTM measures both value delivered, and value not delivered that could have been delivered. This is largely ignored, yet represents a significant opportunity. To understand how the VTC approaches measurement, we need to understand the major value components in the VTC and how they are related.

Project Value - Measuring the Outcome at the Project Level

The four major components that affect long term value delivery are:

� Realized Value

� Project Cost

� Decision Opportunity Cost

� Identification Opportunity Cost



Let us explore each of these in turn.

Realized Value. This is the actual benefit experienced after implementaion. The realized value is delivered, over time, across organizational boundaries. Because of this and other reasons, it is often not tracked for any meaningful period of time. And yet, it is the single most important measure that can tell us how well we are doing overall, across all projects. Why is it important to measure the value delivered across the entire benefit projection period? Business processes have a way of deteriorating. So we need to know, over the entire benefit projection period, what the value delivered was. It is not unlikely that organizations have a tendency to select a “sampling period” that is favorable rather than representative.

Project Cost. This is the familiar budget portion of any project. Under the Value Triple ConstraintTM, it is divided into two separate components:

1. Delivery Cost. This is the usual cost component which is reflected in the budget. This represents money actually spent, whether capital or expense.

2. Schedule Opportunity Cost. Under the Triple Constraint we track the schedule in terms of time. In the VTC, we track schedule in terms of its benefit equivalent. This is both new and different.

To convert schedule time into schedule cost, we need a formula. It is calculated as:

Schedule Opportunity Cost = Monthly Net Benefit x Schedule Months

For example, a project with a projected monthly net benefit of $50,000 and expected schedule of 10 months, would have a Schedule Opportunity Cost of $500,000 ($50k x 10 months). The Schedule Opportunity Cost provides a better mechanism for choosing among alternative schedule options, because it reflects the time cost of delivery - time is money.

Decision Opportunity Cost. While an organization waits to decide, no benefits can be delivered. And so, there is a real cost to the time it takes to make a decision. The quicker we decide, the quicker we begin to realize benefits.

Identification Opportunity Cost. We may recognize that we have an opportunity today. However, an opportunity begins when the conditions that gave rise to it, came to be. So there is virtually always a gap between the time an opportunity arises and when someone in the organization acknowledges it. That gap has an opportunity cost

Identification and Decision Opportunity Costs reflect our capability with respect to those two functions. In many organizations a focus on those two would result in the delivery of much more value to the organization than would a focus on project delivery skills, which might already be quite high.

If project managers wish to be more successful, then the projects need to be more successful

Project Management


from a business perspective. They need to think outside the project because that’s where success begins. A project that will, in the end, deliver very little Realized Benefit is not going to be a business success. Such a project is born handicapped.

Some Uses of Value Triple Constraint

The VTC has these major uses:

1. Quantify the business value of a project

2. Select from alternative schedules.

3. Look for opportunities to deliver more value through speed along the entire opportunity chain.

To reduce risk on a single project, we should continuously update the Value Profile, not just the costs. This would include:

1. Projected Realized Value

2. Projected Delivery Cost

3. Projected Schedule Opportunity Cost

By tracking and projecting all three, we could detect some important things that we don’t currently manage. For example, if the projected Realized Value begins to decline and the Delivery Cost begins to increase, we know there is the risk that the project will be cancelled. And perhaps it should. Also, if the Realized Value after completion shows a tendency to be less than predicted then perhaps projects are being oversold.

On the other hand, when the projected Realized Value increases, then our projected Schedule Opportunity Cost will also increase. This should tell us to revisit the schedule because time has become more valuable.

What about scope management? When an increase in scope results in an increase in the schedule, we should take the additional Schedule Opportunity Cost into consideration. For example, an increase in scope may result in an increase in the Realized Value of $100,000, an increase in cost of only $30,000, and an additional two months of schedule.

Without looking at the schedule impact this seems like a simple decision. But it the benefit was $50,000 per month, then we would incur an additional $100,000 (2 months) of Schedule Opportunity Cost in addition to the $30,000 Delivery Cost. This changes the equation. The organization would be paying $130,000 of value to gain only $100,000. Suddenly it doesn’t make sense any more.



Another example is a change request which is in budget but does not increase the projected realized value. This should be declined because the net Value would decrease and should be declined. Today, the tendency is to accept a change which is in budget, even if it adds no value. Projects exist to capitalize on opportunities. Therefore, we need to measure lost opportunity just as much as measuring adherence to an estimate, which may not even be correct.

Enterprise Value - Measuring the Outcome at the Enterprise Level

How do we determine what the optimal sequence is for projects? Look at the following example. We have two projects requiring the same resources. So which do we do first

From an ROI perspective, Project A appears more attractive and so we might be tempted to do it first. But, by including the schedule cost, we can compare the two alternatives.

The total Realized Value and the total Delivery Cost are the same regardless of order. However, the total Schedule Cost is different for each alternative.

If we do A first, then the Schedule Costs will be:

� Schedule cost for A is 12 months at $50,000 per month or $600,000

� Schedule cost for B is 12 months waiting for A to finish, plus 12 months to complete B for a total of 24 months. Each month is worth $75,000 (benefit from B) for a total of $1.8 million.

� Total Schedule Cost for this alternative is $600,000 + $1.8million = $2.4 million

If we do B first, then the Schedule Costs will be:

� Schedule cost for B is 12 months at $75,000 per month or $900,000

� Schedule cost for A is 12 months waiting for B to finish, plus 12 months to complete A for a total of 24 months. Each month is worth $50,000 (benefit from A) for a total of $1.2 million.

Exhibit 2 - Comparing ROIs

Project Management


� Total Schedule Cost for this alternative is $900,000 + $1.2 million = $2.1 million

Clearly option B is has the least opportunity cost and, therefore, the highest value, which may not be the intuitive choice.

Program, Project, Portfolio and PMO

How do projects, programs and portfolios relate? First, we begin with a quantifiable business opportunity, and designate a program for it. Then, as we determine all the projects required to deliver to the business opportunity, they become part of the program. Beginning at the opportunity/program level provides us with a way to pull necessary projects into the measurable program, rather than trying to group projects after the fact. The VTC can be used to determine the best way to organize and schedule projects within the program and also helps determine sequencing for programs. Once we apply the VTC to a program, we can determine what criteria we wish to use to develop portfolios.

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.

Exhibit 3 - How Projects. Programs and Portfolios Relate



About the Author

Angelo Baratta, PMP, CMC is dedicated to significantly raising organizational capabilities. His ePPMTM framework goes beyond best practices. It is a scientifically engineered system for raising the effectiveness of project, process and requirements management - key competences for all organizations.

Web: http://www.PerformanceInnovation.com

Email: [email protected]

http://www.performanceinnovation.com

mailto:abaratta%40PerformanceInnovation.com?subject=

Project Management


Why Project Scheduling Must Not Become an Extinct ScienceNew demand for project scheduling expertise is driving change in the market place. Learn the key project scheduling strategies for 2010.

After spending the past decade or more dedicated to project management, I noticed during the economic downturn last year a very surprising trend: despite the significant reduction in the number of major Capex projects being sanctioned and funded, the need for third party assistance with schedule analysis and risk assessments actually increased dramatically. After digging into this a little more deeply, I came to the following conclusion: savvy project schedulers are at risk of becoming a dying breed and as project management specialists, we need to do everything we can to reverse this trend.

The software tools available to planners, schedulers and estimators are more powerful today than ever with the likes of collaborative, web-based, multi-user capabilities and yet as a profession we still struggle to bring projects in successfully under the triple constraint of cost, time and scope.

Savvy project schedulers are at risk of becoming a dying breed and as project management specialists, we need to do everything we can to reverse this trend.

A previous survey carried out by Bull Computer systems showed that 57% of projects failed due to inadequate communication and 39% failed due to poor project scheduling. Similarly, well publicized reports such as the Standish Chaos Report all list pessimistic statistics and multiple causes of project failure.

From a project management perspective, my theory is perhaps somewhat more straightforward. I stand behind the belief that there are only two root causes of project failure:

1. The project plan set out by the PM team was unrealistic in the first place.

2. Project execution wasn’t able to perform to the expectations of the project plan.

While, perhaps these causes initially sound very obvious, in reality they are hard to dispute. It’s really all about successfully “planning the work” and “working the plan”...

Why Project Scheduling Must Not Become an Extinct Science


Let’s now consider how to overcome this first cause of failure.

The Keys to Successful Planning

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

It’s All About Top Down Planning

One of the major pitfalls when creating a project plan is to jump straight into the development of the planned work (activities) rather than adopting a more formal, top down approach which tends to be more successful, of defining the project objectives, elaborating scope definition, expanding out the deliverables and Work Breakdown Structure (WBS) and then, and only then, start to detail out the work (activities and resources) required to satisfy these deliverables.

A well-developed schedule should be able to be rolled up through a WBS to show the entire scope of the project with the underlying work required encapsulated as activities. All too often, project plans omit this formal structure which then leads to inevitable project scheduling challenges.

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

Figure A: Deliverable-based Planning

Project Management


give confidence levels as to how realistic these completion dates are.

The term “Risk Analysis” tends to portray impacts from risk events such as weather, mechanical failure etc. In reality though, most risk regarding project success is actually driven by poorly defined scope. In my experience, I have discovered that 75% of the risk exposure within projects actually comes from scope uncertainty and not discrete risk events captured in a risk register. While this is a huge percentage, it is actually good news from a planning perspective as scope definition is typically easier to handle and reduce than external risk events. Again, further proof that a sound project plan needs to be closely tied to a well defined scope definition.

Not only does this certainty-based project scheduling help with pinpointing problematic areas within a project, it also gives the project execution team a range of dates to target rather than being setup for failure against a single date.

Seeing the Wood for the Trees

Sitting in a recent project review meeting, I experienced a project manager requesting a copy of the project plan. When the lead project scheduler provided their 5,000+ activity Gantt chart in a PDF file, the response from the PM was “yes, that’s great but where’s the one the team as a whole can understand.” This is indicative of how schedule’s can be overwhelming to project teams.

Project schedules are designed to capture as much information as possible but in doing so they quickly become hugely complex and unwieldy. Anyone that has tried to determine the paths between say two milestones in a schedule will know first-hand how difficult this can be. To compliment Gantt charts, what is needed is a means of summarizing or grouping key activities, yet still retaining the underlying sequence of work.

Similarly, when analyzing a project looking at cost, schedule, risk and performance, it is much more valuable to be able to do so by selecting groups of activities. These groups may be disciplines, locations and type of work as well as different phases within the project. Having an insight into the scope and associated performance of a project by time phase and by discipline is much more valuable than looking at these metrics averaged out at the project level. This matrix-type of project analysis is an area that is gaining significant traction and one that is hugely valuable to a project team.

Figure B: Project Visualisation Through Ribbons and Phases

Why Project Scheduling Must Not Become an Extinct Science


Analysis Paralysis!

The ultimate objective of developing a project plan is to have a target against which to track performance. Over the years, numerous types of analysis techniques have been developed to try and determine project performance. However, I still go back to the two fundamental causes of project failure. Wouldn’t it be more useful if we could correlate the fact that poor performance in a specific area of a project was actually due to unrealistic planning? In other words, pinpoint the planning weakness so that it can actually be addressed!

Project metric analysis goes well beyond just applying formulas or calculations such as “Total Cost Overrun” or “Number of Activities with Missing Logic.” Instead, metric analysis combines formulas with thresholds or trip-wires that give meaning and context to the results from the formulas. Does knowing we have “fifteen open ended activities” or “five missed deadlines” really tell us anything meaningful? Wouldn’t it be more useful to know the impact of the open ended activities and the cost and schedule implications of the missed deadlines? What if all five missed deadlines were only a day late on a three year project? In this example, it’s arguable as to whether such exceptions should even be reported.

The likes of the Defense Contract Management Agency (DCMA) are now publishing such metrics and trip-wires as a means of standardizing schedule quality checks as well as setting standards for contractors to aim for. Such initiatives are a welcome breath of fresh air to scheduling and I expect to see similar initiatives across multiple industries in the near future.

But the Goalposts Keep Moving...

Maintaining an up-to-date schedule is a difficult enough task during the planning phase of a project but it becomes infinitely more involved during execution.

Figure C: Example of DCMA 14 Point Assessment Analysis

Project Management


During the planning phase of a project, scope invariably tends to be somewhat fluid which in turns results in the required work also being somewhat of moving target. During execution, even in an ideal world of locked down scope, keeping track of actual performance and reflecting remaining work in a schedule can be very challenging and often muddies the true picture as to how well a project is performing.

To overcome this reporting challenge, project trending can give a much more useful indication of performance than simply looking at a single snapshot in time. Knowing a project is ten weeks behind schedule tells us absolutely nothing regarding whether our performance is improving enough to claw the delay back or even worse, if our performance is deteriorating, how much further delay can we expect? With the proper use of a comprehensive metrics analysis tool, this can easily be overcome.

Many projects have done a good job of tracking performance trending during execution, but few actually track trending during the planning phase. Relating back to the first root cause of project failure, project planning is often an iterative process and as such, there is massive value in also running trending analysis against the quality of a plan during the planning phase.

Tying “Planning the Work” to Successfully “Working the Plan”

The second identified cause of project failure was the inability to execute according to a given plan. I believe the solution for the second identified cause of project failure is actually more tied to solving the first identified cause! If indeed we can successfully plan and forecast the work that is required for project completion and this plan then accurately accounts for uncertainties, complexities and risks that may occur during project execution, project failure will then be a thing of the past.

Such a scenario is of course the perfect case, but by adopting the practices described above, we are aligning ourselves more for project success than accepting project failure.

About the Author

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

More information can be found at www.projectacumen.com

http://www.projectacumen.com/

http://www.projectacumen.com

Was Deming Right About Quality Management and Project Outcomes?


Was Deming Right About Quality Management and Project Outcomes?14 points for better project outcomes and consistent quality management

Quality is misunderstood by many who think of it only as it relates to the final deliverable, but a quality product is itself achieved only through quality processes focused on efficiency, innovation, and continual improvement, and these require a quality management culture not only in our projects but within our organizations. In chapter two of his 1986 book, Out of the Crisis, Edward Deming presented 14 principles that he believed could make industry more competitive by increasing quality.

Organizational improvements can begin with anyone. While it’s true that our professional domain as project managers is bounded by the project life cycle, our influence is often much greater than that, and quality management is one of those areas where skilled project managers are best suited to be instrumental change agents -first in the culture of their projects, and second, in the culture of their departments and organizations. As project managers, if we follow Deming’s principles, we can create project environments where quality thrives, not only benefiting our customers and projects but perhaps serving as a tipping point for effecting a quality management change within our organizations.

1. Create constancy of purpose towards improvement

Deming is telling management to stop reacting and plan better for the long-term.

For project managers: What was has been traditionally thought of as long-term planning is no longer achievable. Business changes too rapidly, and detailed, up-front plans take too long to produce and are always outdated by the time they’re committed to paper.

Yet projects must have a plan that establishes activities, milestones, and priorities, so what we should strive for in our projects is thorough planning based on iterative, rolling-wave, or Agile approaches. Thorough planning uses detailed planning for the short-term with a longer-term view emphasizing constant reviews, re-planning, and risk management, especially for opportunities that can be exploited. This results in a project plan that can adapt quickly to abrupt business and deliverable changes without throwing the project into chaos.

Project Management


2. Adopt the new philosophy

Deming is telling management to stop being hypocritical, awaken itself to the challenge, and become leaders.

For project managers: People will always see through anyone who says one thing but whose actions are entirely different. Lasting, energizing change starts first with us, and only then will it spread outward and excite others into action.

As managers, our core values can’t just be expressed through our words, but they must be evident in all our actions with our teams and coworkers. It takes time, but as our message and attitude spread to an ever-broadening base of people, a domino effect takes place and the members themselves become believers and evangelists in quality management themselves.

3. Cease dependency on inspection

Deming is reminding management that the need for inspection will decrease if quality problems are prevented in the first place.

For project managers: We all know that prevention is better than inspection, so our project management and execution processes need continual improvement methods built into them to reduce quality problems.

But inspection goes beyond its purely quality connotations. Are we propagating a management style based on inspection? If our team has a tendency to run everything first past us for approval then we may be, and that isn’t good for us, the team, or the project.

Our responsibility as a project manager isn’t to be the funnel through which everyone seeks approval. If that’s what is happening then the project will stagnate and become inflexible. Instead, let’s make sure we create a project culture where the team has the skills, information, and experience it needs to make every-day, rapid decisions on its own.

4. End the practice of awarding business on the basis of price tags

Deming’s purpose behind this point was to eliminate variations in the manufacturing process by having too many suppliers of component goods.

For project managers: Price alone should rarely be the determining factor because most procurement needs go beyond simple commodities. When a project is likely to involve frequent changes, we need vendors who can adapt or offer their own new ideas for responding to those changes, and that isn’t likely to happen when cut-rate suppliers are chosen.

This principle also holds true in our role as the vendor for internal or external customers. We are not just collectors of requirements — we need to be engaged with the customer and



stakeholders, understanding their business objectives in order for us to provide the deliverable that best meets their changing needs.

5. Improve constantly and forever

Deming is reminding industry leaders that they have to constantly strive to reduce variation, which leads to quality problems.

For project managers: Continuous improvement is a core philosophy of the PMBOK, but it isn’t like a switch that gets turned on or off. It’s a mindset that is nurtured by the right environment. Members of the team need skills, information, and knowledge beyond their core subjects of expertise, and we should encourage experimentation and reward mistakes made in the search for innovation, which means we need to eliminate blame and ingrain the lessons-learned process in every part of the project.

Large-scale improvements and innovative approaches often come from “amateurs” and not specialists because amateurs are driven by their interest in the subject and less wedded to preconceived notions and ideas. Chris Anderson, author of The Long Tail, says, “I’ll take a passionate amateur over a bored professional any day.”

6. Institute training on the job

On-the-job training increases efficiency and results in job outputs with fewer errors.

For project managers: Continuous improvement extends beyond just processes. It applies to the hard and soft skills, experiences, and knowledge of the entire project team. Professional development, coaching, and mentoring should be encouraged, acknowledged, and rewarded.

Training doesn’t have to be expensive, and it doesn’t have to be formalized. Some of the best training experiences involve group-led efforts that also serve as team building exercises, such as webinars, vendor demonstrations, and specific discussions on best practices.

7. Institute leadership

Deming wants management to be leaders not merely supervisors.

For project managers: The problem on most projects is not a lack of management but a lack of leadership. Leadership is more about people skills than about project management skills. Few projects have sponsors that view themselves as the leader on the project, and if the leadership charge is not picked up by the project manager then the project is not likely to be successful. A leader translates the project’s vision into actions that excite, inspire, and motivate the project team, and he or she is able to instill a perception that the project isn’t just creating a deliverable; it’s accomplishing something phenomenal for the customer.

Project Management


8. Drive out fear

Deming tells us that management by fear or punishment is detrimental because it inhibits questions and ideas from the workforce.

For project managers: Fear stifles two cornerstones of quality — innovation and continual improvement. A fearful team isn’t going to generate new ideas and it’s going to hide its mistakes, leading to a poor lessons learned process. Deming’s point goes beyond what most of us associate with fear. Fear is also that little voice all of us hear that suppresses us from speaking up or sharing ideas -fear of failing, fear of sounding silly, fear of making a mistake, fear of missing a deadline, fear of stepping on another’s toes, and so on. Yet these fears are just as detrimental to quality as fear of punishment.

It’s a lack of trust between team members and in the project’s leadership that drives these fears. If we improve trust, team members will be more willing to share their ideas and question existing processes.

9. Break down barriers between staff areas

Deming wants everyone to realize that each person is a customer of someone and that everybody is a supplier to somebody.

For project managers: Silos and a rigid hierarchy are dangerous not only to the project but to the organization. Innovation and continual improvement come about by somebody seeing a connection that is not inherently obvious, and connections can’t be discovered when one is stuck behind artificial barriers.

We can help break those barriers by exposing people to diverse situations outside their normal environment and comfort zones. Though there is a short-term productivity loss when people work outside their specialty, there is a longer-term gain for the project and organization. This strategy helps build a larger pool of “generalists” in many subjects, and new experiences are a powerful motivator for many people. This approach also improves opportunities for innovative approaches and is a risk management strategy should key personnel leave the project.

10. Eliminate slogans, exhortations, and targets for the work force

Slogans imply the problem is with the employees, but the real problem is with the process.

For project managers: The first point we have to accept is that we are responsible for problems within the project, whatever those issues might be. It isn’t the team’s fault, the customer’s fault, or the organization’s fault -it’s our fault.

The root causes of most project problems are deficiencies in communication, scope, requirements, activity definitions, project planning and re-planning, risk management, and



stakeholder involvement. All of these are within our professional domain even if we aren’t the ones personally performing them. It’s our responsibility to make sure the project processes are performed effectively to a level appropriate for the project.

11. Eliminate management by objectives

Setting production targets only encourages people to meet those targets through whatever means necessary, which causes poor quality.

For project managers: On the surface this principle probably sounds like heresy to most of us -how can a project be managed if targets aren’t set? Well, it can’t, but that wasn’t Deming’s point. He’s talking about short-sighted versus thorough planning. Setting targets in response to a problem without first understanding and addressing the root causes in the processes will only lead to more quality problems.

Milestones are the predominant targets for projects, and they need to be challenging to motivate the team, but they have to be achievable and flexible. Yet flexibility is one of the most common scheduling failures a project manager makes, especially on projects that are very iterative and involve rolling wave planning.

As these projects progress, milestones have to be continually reassessed, and this often means that the original dates get pushed. Too many of us perceive these readjustments as “missing our target” because we’re too married to dates that were only best-guesses or top-down estimates set early in project planning. We also should be careful to present milestone dates to stakeholders as estimates and help them understand the iterative nature of these kinds of projects — as the project is better understood and the work needed becomes clearer, milestone dates may change.

12. Remove barriers to pride of workmanship

Deming tells us that nobody feels good about producing shoddy work. When management creates an environment that fosters poor quality, employees are frustrated.

For project managers: Recognizing the team and individuals for their contributions and achievements helps instill pride of workmanship. Everyone on the project team should feel that his or her work is recognized and valuable to the project’s success. Sincere appreciation is one of the easiest and cheapest yet most effective motivating agents we can use. Even “failures” and mistakes are achievements as long as there were valuable lessons learned.

13. Institute education and self-improvement

Deming wants everyone, managers and the workforce, to pursue training, education, and self-improvement.

Project Management


For project managers: Ongoing professional development is expected of certified project managers, but we should also expect and encourage it among our team and coworkers. Nearly every profession has its own certification and continuing education requirements, and our team members will appreciate it if we have a general understanding of their profession’s requirements, recognize them for certification efforts, and help them with opportunities for meeting those requirements.

14. The transformation is everyone’s job

Deming says that everyone is involved in the fixing the processes.

For project managers: This one is easy if we’ve done everything else right because all the other principles will result in quality management culture where everyone is involved in continual improvement and innovation. Having experienced first-hand a quality management experience, the people on our team will in turn spread those ideas to other project teams.

Copyright 2009 J. Alex Sherrer, Project Management Road Trip

J. Alex Sherrer is the author of the Project Management Road Trip for the Project Management Professional (PMBOK, 4th Ed.).

http://www.pmroadtrip.com/

Build Your High-Performance Virtual Team: 7 Key Steps


Build Your High-Performance Virtual Team: 7 Key StepsHow to accelerate virtual team formation and cultivate top-notch teams

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

Joining me in writing this article is Kathy Connolly, founder of The Office Outdoors, a team development consulting firm. We show how some of the essential activities for building any high-performing team can be applied to project teams who must work virtually to get the job done.

Choose the right people

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

Make shared goals explicit

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

Project Management


Develop ground rules tuned to a virtual team

For example, agree on who needs to attend which meetings and how frequently. Be specific about the extent to which multitasking is acceptable on team calls. Discuss the consequences of failure to do important prework. Agree how conflicts will be resolved among members. Establish an agreed-upon protocol for handling distracting, disrespectful or disruptive behavior. Agree who needs to be on the “to” list for certain topics and who can be simply cc’d. Establish conventions for sharing, editing and posting vital documentation, including editing and approval rights.

Facilitate connections

Any time a new team is forming, people need time to cultivate trust to work well together. Team members who work virtually, however, often have few chances to really get to know each other beyond their respective deliverables and due dates. You can facilitate the getting-to-know-you process many ways. For example, invite people to complete a bio that helps to draw out the real person behind the voice. Ask for a picture and information about special skills or qualities, where they’re from and where they live, languages spoken, values they live by, professional credentials, preferred communications method, etc. Post bios on a shared website and encourage people to make connections. Keep in mind that face time is the best way to build a new team. Leverage corporate events, sales meetings and conferences to bring people together without making too big a dent in your budget.

Model best practices

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

Make work fun

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

Build Your High-Performance Virtual Team: 7 Key Steps


Celebrate achievements, milestones and successes

Most projects go through certain phases when the work is stressful and the potential for burn-out or withdrawal is high. Show appreciation for contributions, achievements and sacrifices by making 1:1 contact with each team member. Send cards, either the paper or virtual kind, or personal emails. Or try picking up the phone to say thanks and check in. Get sponsors and other managers involved in showing appreciation, including public acknowledgement via emails, in meetings and in company publications. Plan virtual team celebrations by sending gift certificates for coffee, pizza or dinner. And perhaps the best reward of all: Give team members well-deserved time off when special milestones are met.

Like any other team that’s starting up, a virtual team will undoubtedly move through the phases of forming, norming, storming and performing. Your challenge is to accelerate the time it takes to cultivate a high-performing team by applying sound project team development principles in new ways that reflect the unique dynamics of a virtual team environment.

About the Author

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

Visit her company website at www.guidedinsights.com

http://www.guidedinsights.com

Project Management


Common Project Management Hurdles and the Challenge of ChangeLearn how to manage change issues and improve your project management processes

No matter how well a project is planned and how well the requirements are defined, there will always be requests to change something about the project, usually the product being delivered. There are good reasons for this; business doesn’t stand still while your project is going on so we expect that ongoing business will trigger the need for changes to the system being built to support that business. These changes are mission critical to the project in many cases. If the system isn’t changed to

reflect business needs as they will be when the system is implemented, your project will succeed in building a system to support business as it was done 6 months ago! These changes are why project managers need a good Change Management Plan and process.

Failing to properly plan the project’s work or sloppy requirements gathering will certainly lead to requests for change and will probably overwhelm the project’s resources with change requests to analyze and implement, no matter how solid your Change Management Plan and process are. Failure to define a change management process that meets your project’s needs and plan process activities will lead to: the wrong changes being implemented, budget wasted on the wrong changes, failure to reserve sufficient time for analysis of change requests, refusing changes that would add value to the project, exceeding the budget, and late delivery.

Project length is another source of change requests. The longer the project goes on, the more the business changes, the more the business changes, the more the system must change to support the business. The insulation of the development cycle from the impact of change is one objective of iterative development methods. With iterations, fewer changes are likely to be requested. Software development projects with long delivery time lines can expect to experience a flood of change requests towards their end.

All changes are not created equal. Another common error in the area of changes is the tendency to treat all changes in the same way. The administrative effort required to process a request to change the color of a button on a website screen from red to maroon should not be the same as a request to double the number of pages on the website. Attempts to force requested changes through a laborious process designed to support major changes to project baselines will meet

Common Project Management Hurdles and the Challenge of Change


with resistance. There are two possible outcomes here. Either the team will prevail and will start making the minor changes behind your back or you will prevail and stifle minor changes that ought to be made because they add value to the product.

Yet another common mistake is to have the wrong people make decisions about changes. This mistake is related to the failure to provide different processes for different changes, but it is possible to provide the right process for each magnitude of change and still identify the wrong people as decision makers. The decision makers for a change should be those people, or that person, who has the best grasp of the pros and cons of the change. The decision maker should also be someone who has the authority to approve any budget changes. The decision on whether to approve the change in the colour of the web screen button should be made by someone who is knowledgeable enough about web design to predict its affect on users. The decision on whether to double the number of screens, and probably double the cost of the project, should be made by someone who has the authority to double the budget. This may be a customer, a sponsor, or an executive steering committee.

Project managers often make the mistake of assuming that because they have asked the project team and stakeholders to read a document (e.g. their Change Management Plan) that they will read and understand it. You should make the document available for reading by posting it to a site where everyone you expect to read it has read access, but too often project managers will stop there. The result is usually that changes are made without project approval, and/or the team attempts to follow the process but fail to follow it properly creating more work for the project manager.

Avoidance Strategies

Start your project with a good change management plan. A good change management plan should accommodate any change likely to occur on your project. The plan should support all the best practices described in the PMBOK, but be tailored for the size, complexity, and industry of the project. You should define at least two processes, what I’ll call “Change Management Lite” and “Change Management Full.” Change Management Full should be suitable for large scale changes, up to and including those that must be decided upon by your customer, sponsor, or executive steering committee. Change Management Lite should accommodate the smallest change. Make sure that the administrative overhead entailed in each process is proportional to the size of the change.

A good plan identifies the actions and tasks that must be performed to follow the process, assigns people to those tasks, and identifies any deadlines that must be met. Allow sufficient time in your schedule for the tasks to be performed. Since you can’t predict the number of change requests you will receive, or how complex those requests will be, over the course of the project phase you will need to set buffers. Set your buffer for each iteration, if you are using an iterative development method. One way of dealing with the uncertainty surrounding number and

Project Management


complexity of change requests is to raise an alert when a buffer is approaching total depletion (say 90%). You have two choices when you reach that point: you can shut the change process down (OK if you are almost at the end of the project), or you can request a change to provide more time to deal with change requests. This change will require either more resources (increase the budget) or reducing the scope.

Identify the proper decision makers in your plan. The customer, or client, or sponsors, or executive steering committee should be responsible for making decisions that will change the baseline. These individuals must understand what is expected of them, when they must render decisions, and how they will receive the information they need to make the decision. For changes that don’t change the schedule, budget, scope, or quality baselines, identify one of the project team as the decision maker. You should be the first in line after the executives, but you should not be required to render decisions on issues which do not require a change in the project plans. Take our web page button as an example. It will cost no more to create a maroon color button than it will to create the red version and you are not in a position to know if maroon is the right color. Delegate this decision to the web design expert. The web design expert must follow the change management process. The change will not affect your plans but will affect the design, coding, and testing of the website. Team members responsible for those tasks must be made aware of the change and the appropriate documents updated.

Educate your project team and stakeholders on the change management processes in your plan. Education for requesting a change should include where the change request form resides, how to complete it, who to send it to, when to expect an initial response, when to expect a decision, and how that decision will be made. They should also be educated in their support responsibilities (i.e. answering any questions SMEs who analyze their requests may have). Education for the team should include their responsibilities when they receive a change request for analysis, the deadlines for those tasks, and how the analysis information is to be captured. Education should be in the form of a ½ hour - 1 hour formal training session. Do not throw a process document or presentation over the wall and expect your stakeholders and team members to absorb its contents.

About the Author

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

http://www.threeo.ca

How to be a Project Goal Scoring Champion


How to be a Project Goal Scoring ChampionProject goal scoring for fast, flexible and well trained development teams.

Have you ever seen a group of children play soccer? The ball gets kicked into a corner and every child on the field runs after it. Then the ball gets kicked into another corner and they all chase it there as well. It is exhausting to watch and the game usually lasts a long time, with no/few goals being scored.

This metaphor can easily be extended to poorly run projects. All of the team members wind up ‘chasing the ball’ wherever it goes rather than

spreading the field and playing as a team. Often the same result occurs as the children’s game; a long time goes by without many goals being made. This article will ponder the comparison between a well run project and a well run soccer team.

Soccer Match

1. Watching Children Play

A lot can be learned about running projects from watching children play soccer. It seems that project teams are always ‘chasing down’ the most recent problem like chasing down a soccer ball. That is, they are always running to the next place that the ball is kicked. This problem usually involves the entire team or a large part of it to solve. This means that team members are not working on other aspects of the project, resulting in those areas having problems later. These new problems then require everyone working on them to solve. It seems to be a perpetual loop that is diagrammed below.

Project Management


The result of this loop is that the team is always behind the ball chasing it wherever it gets kicked. This is usually accompanied by lots of yelling from the sidelines by the coach (Project Manager). The next sections will discuss approaches for scoring project goals.

2. Get In Front of the Ball

The best soccer players (and project team members) are those who have learned how to ‘run without the ball’. These players have the ability to anticipate where the ball will go and be there by the time it gets there. By not being behind the ball, they can focus on preparation for when the ball gets to them and they have a better idea of what to do with it when it gets there.

As this relates to projects, having a plan and being able to anticipate where the project will go is critical to the success of the project. If a project is always chasing down issues, then they are being controlled by the issues and wherever it takes them. Staying in front of the issues by scoring project goals allows them to be manageable and allows for preparation as they arise.

The plan must be realistic, however. Having team members ready at a place in the field where the ball will not go makes them unproductive. The plan must also be flexible enough to react to deviations in the track of the ball.

3. Teamwork

One of the biggest keys to getting in front of the ball is to trust in the other team members. This allows the players on the team to spread out themselves across the field and focus on their respective roles. The offensive players in the front need to trust that the players behind them will get them the ball and the goalie needs to trust that the defensive players will do their best to keep the ball away from the goal.

Productive teams also need to trust in each other’s abilities. Designers need to trust that the Requirements were captured properly. Developers need to trust that the Design was done properly. Having this trust allows the team members to focus on their aspect of the project and not have to question all of the other information.

Another key to teamwork is to know where the other team members are located across the field. This allows whoever has the ball to get it to the appropriate person when they are ready to receive it. This results in proper handoffs between team members.

4. Coaching

The coach is critical to the success of the team. Their job is to keep the team focused and motivated to make goals. They see the entire field and can provide valuable insight to the players who are focused on their part of the game. This is why the coach needs to be observant and engaged in what is going on during the game.

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.

About the Author

Kerry Wills has worked as a Consultant and a Project Manager for Fortune 500 companies on multi-million dollar technology projects since 1995. During that time, he has gained experience in several capacities; as a Program Manager, Project Manager, Architect, Developer, Business Analyst, and Tester. Having worked in each of these areas gives Kerry a deep understanding of all facets of an Information Technology project. Kerry has planned and executed several large projects as well as remediated several troubled projects.

Kerry is a member of Mensa and has a unique perspective on project work, resulting in eight patents, published work in project management journals and books, and speaking engagements at over twenty Project Management conferences and corporations around the world. Kerry is a passionate speaker who has a reputation for delivering entertaining presentations combined with vivid examples from his experiences.

Read Kerry’s blog at http://kerrywills.wordpress.com

http://kerrywills.wordpress.com

About ExecutiveBrief


About ExecutiveBriefManage better. Improve performance. Refine processes.

An online periodical for technology managers and business leaders, ExecutiveBrief provides you with quality original content on following topics:

Software Development – Learn about the innovations in the industry, best practices and new technologies.

Outsourcing – Discover the latest industry trends and strategies for success.

Agile – Find out about Agile methods and how to implement Agile practices adding value to your business.

SaaS/Cloud – Find out how to save costs and increase competitive advantage of your business with deployment of Software-as-a-Service and Cloud computing.

Project Management – Learn how to solve and avoid problems in project management, discover the leadership skills necessary for making any project team efficient.

Process Improvement – Stay on track with recent developments in process improvement, discovering how to establish successful business processes to increase your ROI.

Risk Management – Avoid and manage everyday risks in technology business, learn from the examples of successful risk managers.

With a monthly newsletter including the best published articles and blogs, ExecutiveBrief brings the latest trends and information in the IT industry and accompanying opinions from our pool of industry experts directly to your inbox. More articles, blogs and white papers could be found at www.executivebrief.com.

ExecutiveBrief730 SW 4th Street, Suite 3Cape Coral, FL 33991USA [email protected]


mailto:editorial%40executivebrief.com?subject=


A Technology Business Guide to Success

Documents

Transcript of A Technology Business Guide to Success