Knowledge Genes®

The Art of the Executive Summary

The executive summary is often your initial face to a potential investor or project sponsor, so it is critically important that you create the right first impression. It is wise to remember that first impressions are far easier to make than they are to break ~ so if you fail to impress the first time round, the likelihood of an investor hearing your proposition again is very unlikely.

Due to the obvious importance of a great Executive Summary, I have recently been scouring the internet and reading many blogs on the subject when I came across a real gem by Bill Reichert at Garage. He gives a solid 9 point guide that I have listed below. (See Bills original article here)

1. The Grab

You should lead with the most compelling statement of why you have a really big idea. This sentence (or two) sets the tone for the rest of the executive summary. Usually, this is a concise statement of the unique solution you have developed to a big problem. It should be direct and specific, not abstract and conceptual. If you can drop some impressive names in the first paragraph you should—world-class advisors, companies you are already working with, a brand name founding investor. Don’t expect an investor to discover that you have two Nobel laureates on your advisory board six paragraphs later. He or she may never get that far.

See related article:

How to Pitch to Prospective Investors

7 Steps to a Great First Impression

2. The Problem

You need to make it clear that there is a big, important problem (current or emerging) that you are going to solve, or opportunity you are going to exploit. In this context you are establishing your Value Proposition—there is enormous pain and opportunity out there, and you are going to increase revenues, reduce costs, increase speed, expand reach, eliminate inefficiency, increase effectiveness, whatever. Don’t confuse your statement of the problem with the size of the opportunity (see below).

3. The Solution

What specifically are you offering to whom? Software, hardware, service, combination? Use commonly used terms to state concretely what you have, or what you do, that solves the problem you’ve identified. Avoid acronyms and don’t try to use these precious few words to create and trademark a bunch of terms that won’t mean anything to most people. You might need to clarify where you fit in the value chain or distribution channels—who do you work with in the ecosystem of your sector, and why will they be eager to work with you. If you have customers and revenues, make it clear. If not, tell the investor when you will.

4. The Opportunity

Spend a few more sentences providing the basic market segmentation, size, growth and dynamics—how many people or companies, how many dollars, how fast the growth, and what is driving the segment. You will be better off targeting a meaningful percentage of a smaller, well-defined, growing market than claiming a microscopic percentage of a huge, heterogeneous, mature market. Don’t claim you are addressing the $24 billion widget market, when you are really addressing the $85 million market for specialized arc-widgets used in the emerging wocket sector.

5. Your Competitive Advantage

No matter what you might think, you have competition. At a minimum, you compete with the current way of doing business. Most likely, there is a near competitor, or a direct competitor that is about to emerge (are you sufficiently paranoid yet??). So, understand what your real, sustainable competitive advantage is, and state it clearly. Do not try to convince investors that your key competitive asset is your “first mover advantage.” Here is where you can articulate your unique benefits and advantages. Believe it or not, in most cases, you should be able to make this point in one or two sentences.

See related article: 

How to Perform a Gap Analysis

6. The Model

How specifically are you going to generate revenues, and from whom? Why is your model leverageable and scaleable? Why will it be capital efficient? What are the critical metrics on which you will be evaluated—customers, licenses, units, revenues, margin? Whatever it is, what impressive levels will you reach within three to five years?

7. The Team

Why is your team uniquely qualified to win? Don’t tell us you have 48 combined years of expertise in widget development; tell us your CTO was the lead widget developer for Intel, and she was on the original IEEE standards committee for arc-widgets. Don’t just regurgitate a shortened form of each founder’s resume; explain why the background of each team member fits. If you can, state the names of brand name companies your team has worked for. Don’t drop a name if it’s an unknown name, and don’t drop a name if you aren’t happy to give the contact as a reference at a later date.

8. The Promise

When you are pitching to investors, your fundamental promise is that you are going to make them a boatload of money. The only way you can do that is if you can achieve a level of success that far exceeds the capital required to do that. Your Summary Financial Projections should clearly show that. But if they are not believable, then all of your work is for naught. You should show five years of revenues, expenses, losses/profits, cash and headcount. You should also show a key driver or two, such as number of customers and units shipped each year.

See related article: 

6 Steps to Creating a Unique Selling Proposition

9. The Ask

This is the amount of funding you are asking for now. This should generally be the minimum amount of equity you need to reach the next major milestone. You can always take more if investors are willing to make more available, but it is hard to take less. If you expect to be raising another round of financing later, make that clear, and state the expected amount.

If you've any more advice on the Subject, i'd love to hear it... Just pile in with comments below.

See related articles: 

6 Steps to Creating a Unique Selling Proposition

How to Perform a Gap Analysis

7 Steps to a Great First Impression

How to Pitch to Prospective Investors

By Oliver McPhee

8 Shortcomings of Agile / Scrum

Scrum, like most things, has its short-comings (although the pros far outweigh the cons in our view). These 8 theses, according to Robert Martin, are some serious problems with Scrum out of the box:

• No Technical Practices: Scrum is a project management framework and doesn’t make any technical recommendations. Bob suggests that teams “need to borrow technical practices from some other method like XP. The suite of technical practices that should be added probably include: TDD, Continuous Integration, Acceptance Testing, Pair Programming, Refactoring.”
• 30 Day Sprints are too long – most trainers now recommend 1-2 week sprints and the majority of teams settle at 2 weeks.
• Scrum Master sometimes turns into Project Manager: Some Scrum Masters use Scrum as a form of micro management and control. “This is not a problem with Scrum out of the box so much as it is a problem with the way scrum sometimes evolves. Perhaps it is related to the unfortunate use of the word "master".”
• Certification in CSM: The Certificate that a Scrum Master, a trained CSM, holds means that on many teams only that person plays the role. Bob prefers the XP approach of rotating the Coach among members of the team.
• Insufficient Guidance Regarding the Product Backlog: “We've learned, over the years, that backlogs are hierarchical entities consisting of epics, themes, stories, etc. We've learned how to estimate them statistically. We've learned how and when to break the higher level entities down into lower level entities. Epics->Themes->Stories->Tasks.”
• Scrum carries an anti-management undercurrent: “Scrum over-emphasizes the role of the team as self-managing. Self-organizing
  and self-managing teams are a good thing. But there is a limit … Scrum does not describe this with enough balance.”
• Automated Testing: without high quality automated tests it is difficult to work in short cycles and know that stories are really done.
• Multiple Teams: Scrum and generic Agile have little to say about how to scale, many practitioners have ideas but there doesn’t seem to be broad consensus yet.

Other related articles

5 Scrum Transition Anti-Patterns

When the Scrum Product Owner has to say 'No'

How to Implement Scrum

How to Successfully Combine Scrum and Project Governance

The Shared Hallmarks of Agile Methodologies

The people at VersionOne have collated a list of agile hallmarks that are shared across the different methodologies Click for the full original article.

Summarized below are several of the key characteristics that successful Agile projects seem to share. For some methodologies these correspond exactly with individual practices, whereas for other methodologies there is a looser correspondence.

1. Releases and Fixed-Length Iterations

Agile methods have two main units of delivery: releases and iterations. A release consists of several iterations, each of which is like a micro-project of its own. Features, defects, enhancement requests and other work items are organized, estimated and prioritized, then assigned to a release. Within a release, these work items are then assigned by priority to iterations.

The result of each iteration is working, tested, accepted software and associated work items.  

2. Running, Tested Software

Running, tested features are an Agile team's primary measure of progress. Working features serve as the basis for enabling and improving team collaboration, customer feedback, and overall project visibility. They provide the evidence that both the system and the project are on track.

Consistently measuring success with actual software gives a project a very different feeling than traditional projects. Programmers, customers, managers, and other stakeholders are focused, engaged, and confident.

See Related article: >> How to Effectively Deploy Agile Testing

3. Value-Driven Development

Agile methods focus rigorously on delivering business value early and continously, as measured by running, tested software. This requires that the team focuses on product features as the main unit of planning, tracking, and delivery. From week to week and from iteration to iteration, the team tracks how many running, tested features they are delivering. They may also require documents and other artifacts, but working features are paramount. This in turn requires that each "feature" is small enough to be delivered in a single iteration. Focusing on business value also requires that features be prioritized, and delivered in priority order.

Different methodologies use different terminology an techniques to describe features, but ultimately they concern the same thing: discrete units of product functionality.

Methodology	Feature Terminology
Extreme Programming	User Stories
Scrum	Product Backlog
DSDM	Requirements
Unified Process	Use Cases & Scenarios
FDD	Features

See Related articles: >> How to Implement Scrum in 10 Simple Steps

   >> The DSDM Project Life-cycle

   >> How to Utilize eXtreme Programming

4. Continuous (Adaptive) Planning

It is a myth that Agile methods forbid up-front planning. It is true that Agile methods insist that up-front planning be held accountable for the resources it consumes. Agile planning is also based as much as possible on solid, historical data, not speculation. But most importantly, Agile methods insist that planning continues throughout the project. The plan must continuously demonstrate its accuracy: nobody on an Agile project will take it for granted that the plan is workable.

It turns out that Agile projects typically involve more planning, and much better planning, than waterfall projects. One of the criticisms of "successful" waterfall projects is that they tend to deliver what was originally requested in the requirements document, not what the stakeholders discover they actually need as the project and system unfolds. Waterfall projects, because they can only "work the plan" in its original static state, get married in a shotgun wedding to every flaw in that plan. Agile projects are not bound by these initial flaws. Continuous planning, being based on solid, accurate, recent data, enables Agile projects to allow priorities and exact scope to evolve, within reason, to accommodate the inescapable ways in which business needs continuously evolve. Continuous planning keeps the team and the system honed in on maximum business value by the deadline.

See Related article: >> Exploit "Just-Good-Enough" Artifacts

5. Multi-Level Planning

Continuous planning is much more accurate if it occurs on at least two levels:

• At the release level, we identify and prioritize the features we must have, would like to have, and can do without by the deadline.
• At the iteration level, we pick and plan for the next batch of features to implement, in priority order. If features are too large to be estimated or delivered within a single iteration, we break them down further.

As features are prioritized and scheduled for an iteration, they are broken down into their discrete technical tasks.

This just-in-time approach to planning is easier and more accurate than large-scale up-front planning, because it aligns the level of information available with the level of detail necessary at the time. We do not make wild guesses about features far in the future. We don't waste time trying to plan at a level of detail that the data currently available to us does not support. We plan in little bites, instead of trying to swallow the entire cow at once.

6. Relative Estimation

Many Agile development teams use the practice of relative estimation for features to accelerate planning and remove unnecessary complexity. Instead of estimating features across a spectrum of unit lengths, they select a few (3-5) relative estimation categories, or buckets, and estimate all features in terms of these categories. Examples include:

• 1-5 days
• 1, 2, or 3 story points
• 4, 8, 16, 40, or 80 hours

With relative estimation, estimating categories are approximate multiples of one another. For example, a 3-day feature should take 3 times as long as a 1-day feature, just as a 40-hour feature is approximately 5 times as time-consuming as an 8-hour feature. The concepts of relative estimation and/or predefined estimation buckets prevent the team from wasting time debating whether a particular feature is really 17.5 units or 19 units. While each individual estimate may not be as precise, the benefit of additional precision diminishes tremendously when aggregated across a large group of features. The significant time and effort saved by planning with this type of process often outweighs any costs of imprecise estimates. Just as with everything else in an Agile project, we get better at it as we go along. We refine our estimation successively.

See Related article: >> How to play Planning Poker for Agile Estimating

7. Emergent Feature Discovery

As opposed to spending weeks or months detailing requirements before initiating development, Agile development projects quickly prioritize and estimate features, and then refine details when necessary. As features for an iteration are described in more detail by the customers, testers, and developers working together. Additional features can be identified, but no feature is described in detail untilit is prioritized for an iteration.

8. Continuous Testing

With continuous testing we deterministically measure progress and prevent defects. We crank out the running, tested features. We also reduce the risk of failure late in the project. What could be riskier than postponing all testing till the end of the project? Many waterfall projects have failed when they have discovered, in an endless late-project "test-and-fix" phase, that the architecture is fatally flawed, or the components of the system cannot be integrated, or the features are entirely unusable, or the defects cannot possibly be corrected in time. With continuous testing we more easily avoid both the risk that this will occur, and the constant dread of it.

9. Continuous Improvement

We continuously refine both the system and the project by reflecting on what we have done (using both hard metrics like running, tested features and more subjective measures), and then adjusting our estimates and plans accordingly. But we also use the same mechanism to successively refine and continuously improve the process itself.

See Related article: >> How to Revive your Sprint Retrospectives

10. Small, Cross-functional Teams

Smaller teams have been proven to be much more productive than larger teams, with the ideal ranging from five to ten people. If you have to scale a project up to more people, make every effort to keep individual teams as small as possible and coordinate efforts across the teams. Scrum-based organizations of up to 800 have successfully employed a "Scrum of Scrums" approach to project planning and coordination.

See Related articles: >> Avoid 5 Scrum Transition Anti-patterns

       >> A Best Practice Roadmap for Paired Programming

4 Attributes of the Ideal Agile Pilot Project

Successful Agile Adoption in an organization essentially boils down to whether senior management buy-in to it. One of the most important factors influencing this buy-in are the lessons learned from applying Agile to a pilot project. Careful selection of the right pilot project is therefore a critical success factor in the successful adoption of Agile in the enterprise.  

Mike Cohn asserts 4 critical factors which affect the selection of a pilot project

Mike Cohn suggested the four attributes of the ideal pilot project are:

I. Duration – A short project would help skeptics to say that Agile works for small projects. If the project is too large then people would have to wait too long to gauge the status of adoption. Mike suggested that the ideal project length would be somewhere near the middle of what is the average for the organization.

II. Size – The pilot project should be small enough to be done by one team. This abstracts the multi team and cross communication challenges, thus allowing the team to concentrate on the agile process.

III. Importance – Start with a project which is critical to the organization. This would give incentive to the team to work well with the process to ensure the success of the project. A low-importance, low risk project usually becomes just a learning project.

IV. Business sponsor engagement - An engaged business sponsor can help the team if it needs to push against entrenched business processes, departments, or individuals. The time and energy of a business sponsor are critical to the success of the project.

Mike added that all these factors become meaningful with a strong team. Hence, choosing the right team is a precursor to all the above factors.

You might also be interested in these related articles:

How to Implement Agile (including Scrum example)

4 Steps to Agile Transformation

How to Successfully Engage Project Stakeholders

How to Deal with Agile Project Constraints

5 Scrum Transition Anti-Patterns

How to Successfully Combine Agility with Project Governance Oversight

How to Successfully Combine Agility & Oversight

I recently read a very interesting article - 'The Art of Compromise: Scrum and Project Governance' by Mike Cohn. In this article, he asserts that agility (Scrum) and project governance, with a few compromises on either side, combined with the set of actions below, can lead to a successful combination of agility and oversight:

Negotiate and set expectations up front. Undoubtedly, the first Scrum project to go through the governance process in your company will have challenges. There will almost certainly be some things they cannot do; for example, a Scrum team cannot provide a thorough design before getting permission to start coding, because design and coding will be done concurrently. The only solution to this is for the team to negotiate with the necessary governance groups in advance. The more support a team has for this and the higher up in the organization that this support reaches, the better. The team does not need to solicit a permanent change in governance policies. The change can be pitched as a one-time experiment.

Fit your reporting to current expectations. The project review boards or oversight committees that provide project governance have existing expectations for what information each project is to provide at each checkpoint. Don't fight these expectations. If they expect a Gantt chart, provide a Gantt chart. When you can, however, try to slowly shift expectations by providing additional, more agile-friendly information. If burndown charts are suitable to show, do so. Or perhaps you want to include a report showing the number of times the build server kicked off continuously integrated builds and the thousands (or perhaps tens or hundreds of thousands) of test runs that were executed.

Invite them into your process. Scrum teams can supplement less-detailed formal governance checkpoints by inviting governance committee members to participate in the regular meetings they will hold. I like to extend the well-known technique of management by walking around into management by standing around. Encourage managers and executives involved in the governance of a project to attend the daily scrums, where they can stand and listen to what is occurring on the project. The same shift from documents to discussions that is created by working with user stories needs to occur with project reporting. Encourage people to visit the team or join its meetings to see for themselves what is being built.

Reference a success. Nothing convinces like success. Do whatever you can to get a first project or two through lightened or reduced governance checkpoints. Then point to the success of those projects as evidence that future projects should also be allowed through.

It's one thing to look at agile software development in a test tube; it's another to experience it in the real world. In the test tube, agile methodologies like Scrum are easily adopted by all members, and the nasty realities of corporate politics, economics, and such cannot intrude. In the real world, though, all of these unpleasant issues do exist. It is rarely as simple as deciding to use Scrum and then being able to do so with no other constraints.

You might also be interested in reading:

How to Implement Scrum in 10 Easy Steps

Scrum Principles & Best Practices

5 Scrum Transition Anti-Patterns

Best Practices in Agile Development Governance

Process Governance Best Practices

COBIT IT Processes

The Guilty Stigma behind Selling Agile

We in the agile community swear by the principles of the agile manifesto and are the first to mount a stalwart defense against any skepticism that appears online. So why is it so difficult to try and sell your agile adoption plans to management?

Many of us still feel like guilty school children as we try to convince the upper-echelons that we don't need to plan everything first, or that it is actually counter-productive to document every detail (also see Agile Documentation Best Practices) and that a multi-disciplinary culture is far more important than raising individual heroes above the crowd.

It's tough because we're suggesting that to become more efficient, we should effectively do a lot less (see also When Just-Barely-Good-Enough is Good Enough). There is an inherent fear that they may mistake our good intentions for laziness – so if you're not careful you can end up sounding like you're on the defensive straight from the get go. It doesn't help that a lot of the management we're trying to convince happened upon their position by being highly successful at the very same waterfall system that we're insisting is outdated.

The trick is to be confident in your delivery. You aren't selling a completely new methodology; you're phasing in some cultural changes that are proven to increase efficiency and morale in the workplace.

By phasing in different aspects of the agile manifesto you can start to alter the working environment and prove the transition is working with actual results.

I'd be interested to hear your experiences on this topic - the good, bad and ugly.

See other related Articles >>

Agile Enterprise Architecture
Agile Manifesto Model

7 Common BPM Pitfalls

Business process management (BPM) has been a hot topic for the last few years - cited in fact by Gartner as business priority #1 just a couple of years ago. 

I regularly read BPM articles, most of which are sketchy overviews of best practices and so on. Rarely though, do I find articles about the common problems people encounter when implementing 'solutions'. So, to keep balance, here's a list of 7 common BPM pitfalls:

(Related article - Gartner's 3 BPM Worst Practices)

1.  Firing too early

BPM technology tempts you with its promises of visibility, productivity, and fast results. You might be seduced into plowing ahead without methodology, architecture, and process. This is a shortcut to failure. Take the time to get the business, process, and management dimensions of BPM in place first.

2.  Thinking in stovepipes.

Don't think functionally. You need to be thinking end-to-end; about how a value-chain comes together; how your role, performance and productivity create value within the greater process.

3.  Focusing on job cuts.

If you make BPM a veiled headcount reduction initiative, you will guarantee failure. People make processes work and if you use a process initiative to justify a reduction-in-force (RIF) initiative, the program will die.

4.  Solving problems once.

Don't just train an implementation team on how to do a one-time solution. Seek out training and professional development that will "teach them to fish." Figure out how to facilitate sustaining change.

5.  Not supporting users.

BPM empowers process owners and participants to implement change. Be sure you support them with the policies, authority, rewards and recognition, compensation, and other means of facilitation.

6.  Ignoring end users.

Don't over-fund infrastructure at the expense of the process participants: the end users. Treat the users like customers; make them more productive and the technology more invisible.

7.  Hard-wiring the framework. 

You have to design for flexibility. Don't just hard-wire today's answer at the expense of building flexibility to ensure that the answer can change to be effective in tomorrow's world.

Any more to add to this list?

>> other related articles:

3 BPM Worst Practices
How to Structure your BPM Project to Avoid Disaster
5 Steps to Choosing your BPM Suite
Process Governance Best Practices: Building a BPM Centre of Excellence

When the Scrum Product Owner has to say 'No'

One of the key roles in Scrum is that of the Product Owner (PO) who manages the product backlog and helps decides on the product functionality. This is a challenging role where successful execution of responsibilities is pivotal to the project success or failure.

It's easier for people to say 'yes' than 'no' for the now because it mitigates the prospect of short term conflict. However, saying 'no' to the team, to the client or the Scrum Master, is one of the PO's most important tasks.

This list is based on a cool blog I read by Juan Banda at Agile Alliance. 

Situations where the PO might need to say 'NO':

1. When the team wants to force the client to use a technology, platform, architecture or design that it believes to be 'technically suitable' but has no value to the client - I know what's best for you syndrome

2. When the client wants something that is clearly unfeasible with the given schedule and resources - the dreamer syndrome 

3. When the Scrum Master representing the team wants to change the scope for the project - two captains on one boat syndrome

4. When the team decided for themselves what should be excluded from the project - tech decision without involving the business syndrome

5. When developers want to work on an overkill solution for a problem - super engineer syndrome 

6. When the team wants to investigate during several Sprints without guaranteeing practical results - researcher syndrome

7. When the team and Scrum Master want to skip demos - ostrich syndrome

8. When the team want to exclude the PO from all meetings because they believe they already understand the product well enough - come back when I'm ready syndrome

9. When the client wants to communicate directly with the team by-passing the PO - serve yourself syndrome

Also see related articles:
How to Implement Scrum in 10 Easy Steps
5 Scrum Transition Anti-Patterns
The Role of the Scrum Master

7 Simple Steps to Dominate Your Niche ...

Breaking into a new market, let alone dominating it is a challenge - to say the least.

The good news is that today, more than ever before, there's a whole bunch of powerful Web based tools that can bring this goal to life faster and more cost effectively than ever before. But, make no mistake - this will take considerable effort, time and commitment.

The 'secret' is honest engagement and quality content. If this sounds rather too simplistic, let me re-state - this will take considerable effort, time and commitment.

I've built a 7-Step Model of simple things you can do today to get started on this mission - click here to get the ball rolling

If there's any other 'killer' strategies not mentioned in this model, let me know and I'll make the addition.

How to Design & Deliver Effective BPM Governance

BPM governance is critically important, yet it's an area where more clarity and simplicity would be helpful.

The ultimate goal of a successful BPM program is the proactive, efficient management and continuous improvement of the set of process (and their sub-processes) by which an organization delivers value to its customers and other stakeholders - there it is.

5 key elements to Business Process Management (BPM) governance are:

1. Measurement
2. Ownership
3. Accountability
4. Control
5. Support

This Knowledge Genes (below link) captures the key points on how to effectively design & deliver BPM governance as well as some 'deadly sins' to watch out for, else problems abound:

Design & Deliver Effective BPM Governance