Knowledge Genes®

The Best Questions for Interviewing Stakeholders

The key to any successful elicitation is asking the right questions. Based on an incredibly useful article I found by Mark Monteleone, this list of questions will help you successfully start any elicitation, regardless of scope.

Related articles:

How to Successfully Conduct Stakeholder Interviews

How to Become More Confident in Requirements Elicitation

Key stakeholder questions

Capture business requirements that trace back to the stated business needs in the project vision and scope. 

• Describe how your organization fits into the company?
• How does your organization contribute to the strategic plan of your company?
• Where are your organization’s locations?
• What is your management organization structure?
• What are the processes of your organization? What business decisions (business rules) are made in your processes? Who owns the processes? What process measurements are used? What regulations are abided by?
• Who are your suppliers and what do they provide your organization? Who are your customers (internal/external) and what does your organization provide them?
• How does the organization measure its success?
• How does the organization obtain feedback from its customers?
• Are there any significant organization events during the year?
• What is the single item which will make this organization more successful?
• What is the single item which will make this organization less successful?
• On a scale of 1 to 10 (10 being highest) where would you put this organization regarding the risk to the company and why?
• What doesn't get enough (or gets too much) attention in the organization?

User questions

Capture user requirements for later analysis

• Descibe your role in the organization?
• What are your major responsibilities? What business decisions (business rules) do you make in your job?
• With whom do you interact to carry out your responsibilities?
• What information do you use in your job? What forms do you use?
• What computer systems do you use in your job? Are there any events for which the system provides alerts? Are there any new alerts needed?
• How do you measure success in your job?
• What is occurring that is helping/inhibiting you to do your job?
• What skills are needed in your present job?
• What training did you receive for your present job?
• What would you change about the way you carry out your responsibilities?
• What do you see as the major critical issues facing the organization?
• What areas for improvement have you observed?

Condition questions

Capture the environmental conditions that are needed along with the capabilities of the system.

• How quick do you need the system to respond?
• How many users will use the system at the same time? What is the user growth expected?
• When does the system need to be available?
• Are there any environmental considerations for the system (weather, heat, cold, sunlight, humidity, power, etc.)?
• What type of on-line help is needed for novices? What short-cuts are needed for power users?
• What formal system training is needed? What formal system documentation is needed?
• What frequency of backups is needed? How long do transactions need to be retained? For extensive outages, what disaster backup and recovery are needed?
• What level of security is needed? What audit requirements are needed?

Legacy questions

Capture system transition requirements needed for a smooth system implementation.

• Does a legacy system need to continue for a period of time after the new system is implemented?
• Do any data files or business rules need to be conveyed upon implementation of the new system?

Sponsor questions

Capture feedback on how change needs to be managed.

• In your opinion what are the project risks? What are the chances of success vs. failure? Why?
• How will you measure the success of the project? How will you measure the success of the business impact of the project?
• If you received additional funding for this project, what would you do with it?
• If you received additional time for the project, what would you do?
• What items could be discarded from the project plan and no one would notice or care?
• If you could have anyone in the world work on this project, who would it be and why would you want that person?
• What information do you want to keep abreast concerning this project?
• How often and by what means would you prefer to be informed about the project?

Other related articles

How to Effectively Run a Requirements Workshop

How to Successfully Conduct Stakeholder Interviews

How to Become More Confident in Requirements Elicitation

Best Practices for Stakeholder Engagement

 

- Mark Ridgwell

10 Top Tips to Protect Sensitive Data from Malicious Insiders

Last year Microsoft warned organizations to expect an increase in "insider" security attacks by disgruntled, laid-off workers. This seems to be a sensible warning, considering the current struggling economy. Most organizations would agree that some of their most valuable assets reside within applications and databases. Most would probably also agree that these are areas that have the weakest levels of security.

Based on an article by Brian Contos, Chief Security Strategist, Imperva, this is a list of the top ten ways of protecting sensitive data from the very people who need access to it:

1 To secure it you have to know about It

Organizations may not know where sensitive information is in order to protect it. Once the databases and related data stores have been identified, it’s vital to classify the sensitive data and identify the objects contained.

2 Don’t trust native database tools

If a malicious insider has access to the database and can possibly manipulate the native database audit logs, then these logs are useless. Capturing database audit logs should be done independently of the database tools, thus enforcing separation of duties.

3 Monitoring the good and the privileged

Insider threat is more about detection than prevention. That means monitoring how ALL users are interacting with your sensitive data.

4 Profiling isn’t just for the FBI any more

It is important to profile application and database interactions. This enables better protection against simple attacks like SQL injections and helps identify more subtle attacks such as those that target business logic flaws.

5 You can’t arrest an IP address

The reconciliation of Web application and database activity should be done outside of the Web application and database and be independent of vendor, version, etc. Tracking user sessions in this way allows for greater control of session tracking without putting additional resource strain on the Web and database applications themselves.

6 Augmenting machine-based analytics with human intuition

Because IT security may not have the ‘big picture’ for every person in every organization, it’s important for the reports to be reviewed by various stakeholders such as non-technical managers, HR, and legal. This combination of real world analysis supported by detailed application and database evidence can yield more accurate results.

7 Forensic crime scene investigations through audit logs

In most insider threat investigations, once signs of malicious activity are identified, three questions are asked:  what else has the insider done, how long has this been going on, and who else might be involved in similar activities. Leveraging visual analytics to investigate attacks can result in flagging malicious activity in minutes.

8 Sensitive data resides in databases

Two solutions that work well for the needs of DBAs and IT security are Database Firewalls (DBFW) and Database Activity Monitoring (DAM) solutions. Together these provide a combined solution for database protection, monitoring, and auditing that is completely independent from users.

9 Users get to databases through web applications

While sensitive data resides within the database, most users access that database through a Web application. Many organisations use a Web Application Firewall (WAF), modern WAFs are able to protect against technical attacks, business logic attacks, and provide a number of correlation, profiling, and adaptive capabilities needed to address today’s complex attacks. See also - How to Create a Secure Public Website

10 Needles hiding in stacks of needles

Insider threat analysis benefits from multiple sources of data-centric information because a single source might not provide the complete story. Discovery and classification should be used to identify critical assets and the information they contain. WAFs should be leveraged to protect applications, DBFWs to protect databases, and DAMs to provide database auditing.

>> People who viewed this article also viewed:

How to Create a Secure Public Website

How to Protect Against Identity Theft

COSO Framework for Enterprise Risk Management

7 Step Information Protection Plan

10 Most Influential Software Development books of the Past 10 Years

Larry O'Brien at Knowing.net has put together a list of the 10 most influential software development books of the decade (Published between 2000 ~ 2010). (See Larrys list here)

• Lean Software Development: An Agile Toolkit
• Practices of an Agile Developer: Working in the Real World
• Head First Object-Oriented Analysis and Design
• Beautiful Code: Leading Programmers Explain How They Think
• Code Complete: A Practical Handbook of Software Construction
• Programming Ruby 1.9: The Pragmatic Programmers’ Guide (Facets of Ruby)
• Effective Java (2nd Edition)
• Concurrent Programming on Windows
• Java Concurrency in Practice
• Producing Open Source Software: How to Run a Successful Free Software Project

We all have our own opinions on this very subjective topic, so I thought I'd ask our readers what books (if any) they would add to their list?

See other related articles:

The Principles of Object-Oriented Class Design
7 Habits of Highly Effective Programmers
5 Tips to Help you Improve your Design Skills
Ensure a Structurally Harmonic Design
Improve Website Performance

By Oliver McPhee

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

By Oliver McPhee

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

By Oliver McPhee

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