4squareviews

At the PM Symposium 2015 event held at the PMI Chicagoland chapter last Friday, I had a chance to see several presentations.   One in particular caught my eye:  it was called “Traditional PM, Meet Agile:  Navigating Your Changing Role” and was presented by a team of two people.   Jeff Singleton who runs The Project Factory, Inc., and Jeanine Izzo, who runs Viage Partners, Inc.   Jeanine was the voice of traditional PM, and Jeff represented the voice of agile PM, because he has had more work experience in the agile world than Jeanine has.

The Project Management Continuum

In the entrance to the presentation, they had a poster which had the words THE PROJECT MANAGEMENT CONTINUUM on it, with T for Traditional at one end, and A for Agile on the other.   They had people mark with a circle where they stood on their PM journey in transitioning from traditional to agile project management, and they also had people mark with a square where their company stood in that transition.

The results of the informal survey were as follows:

If traditional is -3, and agile is +3, with 0 being the midpoint, the median response was somewhere between -2 and -1.   NO one was as far as +3 on the agile scale.   Interesting, it seemed as if the companies were clustered more between -3 and -2, which shows that people are farther along the way to transitioning to agile than their companies.   This became a theme in the Q&A session after, where many people said as project managers, their teams were agile but that management was traditional, and one of the challenges they faced was, not only running an agile team, but also translating the progress on the project into “traditional PM” language so that the management could understood what was going on.

The main point I liked about this “continuum” survey was that it is NOT about “traditional vs. agile”, it’s about learning how to speak two different PM languages if you will so that you can translate between the two worlds with agility (pun intended).

5 Comparison Areas

The next section of the presentation was a compare and contrast exercise, with the “contrast” part coming first.   Here are five areas of comparison between traditional and agile PM and a sample of each comparison that was given at the presentation.  I don’t want give the entire content of the presentation, because my hope is that those who are interested can contact Jeanine Izzo at

http://www.ViagePartners.com (630) 833-8357

and Jeff Singleton at

jsingleton@leanprojectframeworks.com (847) 710-7137

to arrange to have this presentation done at your company or organization.

You can see that the focus is different for each topic between traditional and agile PM.

5 Skill Areas

The main point in this section of the presentation was to emphasize that knowing traditional PM is not a barrier to learning agile PM; there are certain skill sets that carry over from traditional to PM, such as

1. Working with a Framework
2. Discipline
3. Problem Solving
4. Presentation
5. Use of Tools

However, rather than replacing these traditional skills, you will add to them in agile PM.   Here are five skill areas you will need to develop.

1. Strategic Thinking
2. Flexibility
3. Transparency
4. Facilitation
5. Learning the Agile Framework

As a final exercise, in order to have this be the beginning point of a journey, rather than just an interesting stop along the way, Jeanine and Jeff suggested that we all rate the 10 skills above, both traditional and agile, according to how satisfied you are with your development.    You can either rate each one individually from 1 to 10 (with 10 meaning “highly satisfied”), or do I like I did, where you rate you each of the skills collectively.   For example, I was highly satisfied with my presentation skills do due to my five years of experience in Toastmasters.    I was least satisfied with my discipline skills as I am constantly struggling to get more organized.

Once you do the exercise, then take one or two areas from the list (usually the skills you are least satisfied with and pick at least one action item you want to work on for each area.   Or if you are very motivated, pick an action item for each of the 10 skills, but then prioritize these.

Conclusion

The German psychoanalyst Karlfried Graf-Durkheim once said, “if you are on a journey, and the end seems to be getting farther and farther away from you, then at some point, you realize that the end is the journey.”   In going towards the agile end of the continuum, your goal is not to arrive, but to navigate the journey.   I certainly felt that the presentation by Jeanine Izzo and Jeff Singleton ended up being an extremely helpful guide on that journey.   I can certainly recommend that you get in touch with them so that they can help you on your journey as well.

Filed under: Uncategorized | Leave a comment »

An agile contract is one that is designed for an agile project management environment.   In my last post, I discussed the three different types of contracts in traditional project management to give a contrast to the agile contracts discussed in this post.

Traditional PM Contract Types

As a recap, here are the three types of contracts used in traditional PM.

Three Types of Contracts in Traditional PM

The three types of contracts in traditional project management are:

1. Fixed price
2. Time & material
3. Cost reimbursable

In terms of cost risk, you can list the three types of contracts in the following way, where a higher cost risk to the seller is to the left, and a higher cost risk to the buyer is to the right.

Fixed Price –> Time & Material –> Cost Reimbursable

Fixed price contracts tend to be used when the scope is predictable, and thus a fixed price is readily obtained for the component.   Cost reimbursable contracts, on the other hand, are used for when the scope is NOT so predictable, and thus the cost of the component cannot be so readily obtained.

Inherent in the fixed price and cost reimbursable contracts are the tension between the seller and buyer in terms of cost risk; fixed price favors the seller and cost reimbursable favors the buyer.   That is why there are mechanisms in place (ceiling price, incentive fee, etc.) to make the cost risk more equitable on either side.

Agile Contracts Types

In agile contracts, on the other hand, all three types try to balance the cost risk between seller and buyer, and the difference comes to not how they are structured in terms of cost, but how they are structured in terms of time.   Agile iteration contracts are done for the duration of an iteration.  Time & Material contracts are done for an arbitrary period of time.  Phased development contracts are done on a quarterly basis.

One feature that agile contracts have in common with traditional PM contracts is that they tend to be risk management tools.   In the case of traditional PM, the focus is primarily on cost risk.

1. Agile Iteration Contract–this is based on each team delivering agreed upon features to defined quality standards by iteration end.   NOTE:   The Product Owner is NOT allowed to change the iteration backlog DURING the iteration.
2. Time & Material–this is based on a customer continuing to pay a customer during an agreed-upon time period until such point that the customer doesn’t see value being added, at which time the customer stops paying and the contract ends.
3. Phased Development–this is based on the team achieving a successful release of the product.

In agile contracts, cost risk is a factor as well, and the time period of the contract is chosen based on the needs of the customer and the size of the project, but the agile contract helps manage other areas as well.   Here is a chart showing how the four areas of scope, risk, communication, and cost management (related to issues of invoicing and payments) are dealt with in the three types of contracts listed above.

The overall point to remember with agile contract is that the relationship between the customer and team is paramount; the contract is merely a formalizing of that relationship and a way of dealing with risks that may occur in the future so that the customer and team can essentially put them aside and focus on their working relationship in the present.

This concludes my survey of the three processes listed in the Initiate Process Group and the Value-Driven Delivery knowledge area.   The next post will cover those processes in the Initiate Process Group that fall under the third knowledge area, “Adaptive Planning”.

Filed under: Uncategorized | Leave a comment »

An agile contract is one that is designed for an agile project management environment.   In my last post, I discussed properties that all agile contracts share.   In this post, I do a recap of traditional project management contracts in order to give a context for how agile contracts differ.

Here are the elements of the Agile Manifesto as created in 2001 by the Agile Alliance:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Note that the word “over” appears in every element of the manifesto.   The one relevant to agile contracts, of course, is element #3, “customer collaboration over contract negotiation.”   This means that contract negotiation is necessary, but that the priority needs to be placed on customer collaboration.   Why?   The creation of a contract in and of itself does not add value from an agile standpoint; the value is created in the customer collaboration and the contract is a mere formalization of this collaboration.

The agile contract acts as a type of risk management response.   What happens if things do not go as smoothly as the customer and the company doing the project envision at the beginning?   In a way, by making sure that there are contingencies for those possible future events (i.e., the risks), you can make sure that the team is spending all of its energy on creating value for the customer in the present moment.

Before I discuss the three types of agile contracts, let me review the three types of contracts used in the traditional project management environment.

Three Types of Contracts in Traditional PM

The three types of contracts in traditional project management are:

1. Fixed price
2. Time & material
3. Cost reimbursable

Fixed Price Contracts in Traditional PM

These three differ with regards to how they answer the question:   who bears the greater share of the cost risk?    Let me explain first what the cost risk is before we explore this question.   The seller creates a product for the seller.   The amount of money it costs the seller to create the product is the “cost”, and the seller adds to the cost the amount of profit the seller wants to make, called the “fee”.   The “cost” and the “fee” together make what the buyer will pay the seller, namely, the “price” of the product.   In a fixed-price contract, if the “actual cost” of the product is higher than the “target cost”, the seller will pay the “target price” no matter what.   This means that, as the actual cost goes up, it eats into the fee or profit margin of the seller, and if it goes too high, i.e., higher than the target price, then the seller will actually lose money.   This is why the fixed-price contracts favors the buyer in terms of cost risk.

Cost-Reimbursable Contracts in Traditional PM

Let’s skip to the third type, cost reimbursable.   In this case, the buyer guarantees to pay the target price, no matter what the target cost is.   This is obviously favoring the seller rather than the buyer in terms of cost risk.   There are ways to balance the cost risk by using devices such as a “ceiling price” or a “cost incentive fee”, which I won’t go into here.   But traditional project management acknowledges that the cost risk favors one side or the other, and adjustments can be made to the basic two contracts type of “fixed price” and “cost reimbursable” to address that imbalance.

Time & Material Contracts in Traditional PM

The second type of contract has a cost risk which in some ways favors the buyer and in some ways favors the seller, and that’s why I put it in between the other types which clearly favor one side or the other.   When I was working for a Japanese manufacturer doing litigation management, our company would hire lawyers to help defend the company in the case of a lawsuit.   They were paid on a per-hour basis, with the fee depending on the experience of the attorney.

This is a typical example of a time & material contract.   We paid for the services of a person who worked for us on a per-hour basis.   How does such a contract favor the buyer (our company)?   The fee structure would not change during the duration of the case, so there was an element of predictability about it.   On the other hand, the fact that the number of hours worked by the lawyer was not fixed favored the seller (the law firm the lawyer belonged to).

So in terms of cost risk, you can list the three types of contracts in the following way, where a higher cost risk to the seller is to the left, and a higher cost risk to the buyer is to the right.

Fixed Price –> Time & Material –> Cost Reimbursable

In agile contracts, on the other hand, all three types try to balance the cost risk between seller and buyer, and the difference comes to not how they are structured in terms of cost, but how they are structured in terms of time.

With that background regarding the three types of contracts in traditional project management, let us turn in the next post to the three types of contracts in agile project management.

Filed under: Uncategorized | Leave a comment »

The second chapter of John Stenbeck’s book, “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, contains an Agile Project Management Processes Grid, and process 2.3 is the third process in the second knowledge area called “Value-Driven Delivery.”    This knowledge area covers for agile project management the equivalent of both scope management and quality control portion of quality management in the traditional project management framework.   The quality assurance portion of quality management is covered in the “Continuous Improvement” knowledge area, the last of the seven knowledge areas in the Agile PM Processes Grid.

Contracts and Agile PM–The Fundamental Disconnect

There is a fundamental tension between the idea of agile, which tries to minimize formal documentation, and the idea of a contract, which is the ultimate form of formal documentation.    Unless you are an attorney, creating a contract is not a value-driven process.   It is the formalization of the agreement between your company and the customer, which is a result of a conversation that is, in fact, creating value.

However, it is necessary, and therefore, the way to create value with a contract is to a) make sure it accurately reflects the agreement reached in conversation with the customer (where the value is actually created), and to b) minimize the time spent negotiating and creating them.

4 Elements of Contract Suitability

Given the above, what  elements can be used to determine whether a contract is suitable for an agile project?

1. Project objectives–it should include the elevator statement and product vision, as well as the project data sheet
2. Roles and Responsibilities–the agile process should be defined, as well as the Product Owner and any other key team roles, with a clear statement of their roles and responsibilities
3. Scope delivery–the method of scope delivery (i.e., backlog grooming) is specified, as well as go/no-go checkpoints;
   and a clause is included for cancelling for convenience at the end of iteration by either party
4. Risks and rewards–cost responsibilities are shared using a target cost principle (where both parties bear the excess cost of changes beyond the target cost); clauses are added for a bonus, penalty, early determination and/or late delivery.

Summary

In general, an agile contract divides shared risk between the parties and defines the trust points between the parties.  It helps avoid problems related to unrealistic promises or demands, or poorly defined functional expectations.   It must be created in the spirit of win-win, rather than “I win, you lose.”   Properly created, it is a springboard for mutual creativity between the parties, not a prison that keeps it from thriving.

There are three possible types of agile contracts

• Agile Iteration Contracts
• Time and Materials Contracts
• Phased Development Contracts

which will be compared and contrasted in the next post.

Filed under: Uncategorized | Leave a comment »

In John Stenbeck’s book “PMI-ACP Exam Prep PLUS Desk Reference,” he creates an Agile Project Management Processes Grid, and in this series of posts I am covering those in the Initiating Process Group, and the Value-Driven Delivery knowledge area.

To my mind, “Value-Driven Delivery” in Agile covers some of the same ground as “Scope Management” and the quality control aspects of “Quality Management” (quality assurance aspects are covered in the “Continuous Improvement” knowledge area in agile).

Business Case–Definition

It is a written document that explains how the use of the company’s resources is aligned with the creation of the product, service or result that will be created by the project, and that the benefits to the company for doing the project will outweigh any costs and risks.

In other words, it ties together three elements:    the product, the business need (the reason why the customer wants the project done), and the strategic objective of the company (the reason why the company wants the project done).   If the business need goes away, then the project will go away as well.   If the strategic objective of the company goes away, then the project will go away as well.

Business Case–Acceptance Criteria

What are the criteria for accepting or rejecting the business case?   It should accomplish the following:

1.  Provide context and background of the business environment and need.
2. Outline options for meeting those needs, and recommending a solution
3. Defining success metrics for the proposed solution
4. Analyze the related cost/benefit and financial ratios
5. Present a compelling case for change that secures executive support
6. Secure executive approval

The business case should include a business model snapshot, a visual picture that helps illustrate some of the criteria above.   It should include the following elements:

1. Critical success factors and goals (related to criterion #3 “Defining success metrics” above)
2. Process maps of the current and future processes (related to criterion #5 “Present a compelling case for change” above)
3. Opportunities for process improvement (also related to criterion #5)

The process maps listed as element #2 of the business model snapshot should include the following:

• Roles and responsibilities for the various processes
• Business rules that affect the various processes
• Workflow diagrams that show how work gets passed from one process to another

The process map is a high-level visual picture of the major process steps broken down to individual sub-processes if necessary.   It helps improve understanding of business processes by breaking them down into simple visual steps.   This helps identify problem areas such as bottlenecks, processes that do not add value, and gaps where processes could be added that do create value.   It needs to be accurate in terms of its details, but nevertheless easy to red and understand.

Detailing the Solution

Criterion #2 for a successful business case is recommending a solution for meeting the business need described in criterion #1.   This solution is clarified by

1. Identifying the stakeholders who will be impacted by the solution
2. Identifying the business systems and processes that will be impacted by the solution (the “process map” is helpful here).

If these elements are present in a business case, it will help make the case to the customer that your company is the right one to do the project, and it will make the case to management that this project is the right one for the company.

The next post is on Process 2.3 “Contracts”.

Filed under: Uncategorized | Leave a comment »

Based on Brian Tracy’s Goals program, I have used a planning journal to write down my main inspirational goals each year, and then to break down those goals into monthly and weekly goals.

For about a year, I took Brian Tracy’s recommendation to the next level, and wrote down my daily goals.    I found that doing this took about half ah hour, and he recommended doing it the night before rather than the morning of each day.   Here’s the practical problems I found with this approach.

First of all, I was often tired and doing a detailed laundry list of everything I had to do, and then prioritizing each item and putting them in a schedule was often mentally tiring.   However, saving it to the next morning when I had the physical energy wasn’t the best option either because I would have the physical presence of mind before my first cup of coffee to be able to do the daily plan.    And sometimes deciding what time I would have to get up would depend on what was in the daily plan, particularly if it was a weekend day.    Could I sleep in until late, or did I have to get up early?

The second problem was that the best laid plans of mice and men often go astray–sometimes even by the time I get to work.    One of the first things I do is check my phone-mail messages and e-mail message, and an urgent message from either one of those channels might alter my daily plan considerably.

It wasn’t until I got the work Getting Things Done by David Allen that I got a better, more flexible way of organizing my time.  And it wasn’t until recently when I started studying Agile project management that I understood why it worked better.   That discussion is the subject of today’s post.

Getting Things Done

In David Allen’s system, he recommends taking larger, aspirational goals and breaking down them down, just like Brian Tracy recommends.    However, he recommends stopping at the level of the weekly plan.     Let’s say on Sunday you draw up a weekly list of what needs to get done in the various areas of your life.    What do you do on Monday morning (or Sunday evening, the night before)?    You draw from that weekly plan those elements that you are going to aspire to get done during that day, based on urgency (how quickly it needs to get done) and priority (how important it is to get done).

This worked out a lot better.    Every day I would choose 10 items that I wanted to get done, and I would focus in on that list.    Yes, there were times that I would get an urgent message via telephone or e-mail, and have to add an item to the list.    But adding one item to a list of ten is a LOT easier than having to scrap an entire daily plan.    I figured that, at a minimum, I was saving 3 hours a week by not having to draw up daily plans.    The daily list would take 5 minutes at the most.    And at the end of each day, those items that I got done on my daily list would get checked off on the weekly plan and voila, by the end of that week I would have most of the weekly plan accomplished.    It was thorough enough to capture everything that needed to get done, but flexible enough to accommodate the changing circumstances that come from …. well, life itself.

The Agile Way

In preparing the material from chapter 2 “Introducing Agile Project Management” of John Stenbeck’s book “PMI-ACP Exam Prep PLUS Desk Reference”, I suddenly got why the David Allen system was an improvement on Brian Tracy’s goal program.

The larger yearly or monthly plan was the roadmap that listed my aspirational goals over a long period of time.   From this, I derived the weekly plan, which was like a release plan in agile PM language, that I would use to capture all of the deliverables I wanted to complete by the end of the week.    The iteration plan was the daily list I would draw that would draw from the release plan or weekly plan those elements I wanted to complete during that day.    I would focus all of my energy on that iteration plan or sprint and not be concerned about the totality of the weekly plan.    That would improve my focus and keep me from being overwhelmed at the number of items to be done on the weekly plan.

The David Allen system is an agile version of the more traditional system that Brian Tracy advocates.    The breakdown process is the same, but the David Allen does not try to completely describe the exact scope for each day–life is too chaotic to be hemmed in by such a rigid system.

Now when I do my daily list I even call it “today’s sprint” to honor my newfound understanding that I am, in reality, using agile project management not just in my profession, but in making my daily life run more smoothly.

Filed under: Uncategorized | Leave a comment »

In the book “PMI-ACP Exam Prep PLUS Desk Reference”, John Stenbeck created an Agile PM Processes Grid, which has 87 Agile PM Processes divided up between the 5 process groups and 7 knowledge areas.

I just got done summarizing the first block of processes, those in the first process group (the Initiate process group) and the first knowledge area (External Stakeholders Engagement).

Now, I am embarking on a description of the second block of processes, those in the first process group (the Initiate process group) and the second knowledge area (Value-Driven Delivery).

These three processes are as follows:

Process 2.1 Value Analysis
Process 2.2 Business Case
Process 2.3 Contracts

The next post was going to cover the first of these three processes, Value Analysis.   However, this process seems to be missing in John Stenbeck’s textbook.    I assume he is talking about Business Analysis in the agile PM context, but I want to contact him and make sure that is what he is referring to.

Filed under: Uncategorized | Leave a comment »

In the Agile Project Management Processes Grid presented by John Stenbeck in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, the process that comes right after Process 1.1 Stakeholders Identification is Process 1.2 Vision Statement.

For reference here the four agile tools which are used in the process of defining and clarifying the vision for a releasable product:

1. Vision Statement (Process 1.2)–sometimes called an elevator statement, an uncomplicated way to define the product vision in a short statement
2. Product vision box–a tangible expression of a solution that includes whatever context is necessary to convey what the product will be
3. Product data sheet or PDS (Process 1.3)–one-page summary of key project objectives, capabilities, and information that convey how a project fulfills the product vision
4. Flexibility matrix–a tool that communicates how to handle trade-offs with a grid showing the relative importance of constraints such as scope, schedule, cost, and quality by defining them as fixed, firm, or flexible (only one constraint may be fixed)

The last post covered the third agile tool mentioned above, the Product Data Sheet or PDS, which also happens to be Process 1.3 in the Agile PM Processes Grid.   This post will cover the fourth agile tool listed above, the flexibility matrix.

The Flexibility Matrix

As discussed in a previous post, in traditional PM, the scope is fixed as much as possible in the beginning of the project, and the other two of the triple constraints of time and cost are estimated in relationship to this more-or-less fixed variable.

In agile PM, it is one of the two triples constraints of time or cost, usually time, which is the fixed variable, and the scope is the one constraint that is flexible.    Okay, in theory that it is understandable, but when push comes to shove, and some of the scope has to be thrown out of the project, how do you make that decision?    That’s where the flexibility matrix comes in.   As mentioned above, it shows how to handle trade-offs and prioritize features by showing the relative importance of constraints such as scope, schedule, cost and quality (although other constraints may be added to the matrix).

NOTE:   When using the flexibility matrix, only one constraint may be considered fixed, all of the others have to be defined as firm or flexible in relationship to this fixed constraint.    In the example below, the flexibility matrix is given where the schedule is fixed, the scope and quality are firm, and the cost is flexible by comparison.

Usually the flexibility matrix is incorporated into another tool called the Product Data Sheet, which was covered in the last post.   This is a one-page summary of key project objectives, capabilities, and information that convey how a project fulfills the product vision.    Here is the above flexibility matrix incorporated into a Product Data Sheet which I made up to represent an actual language-learning app called Duolingo which I use every day to study foreign languages.

Product Data Sheet incorporating Flexibility Matrix

The Product Data Sheet has elements which are geared towards the customer (the elevator statement, customer segment, and customer benefits), towards the team (the milestone table), and to both the customer and the team in facilitating any conversation that comes up about trade-offs (the flexibility matrix).

Process 1.4 Active Listening is a tool used in Agile PM when conducting any conversation with stakeholders, like the one referenced above when considering trade-offs between various features.    It is one of the most powerful tools of the agile practitioner’s toolkit, and I will cover it in the next post.

Filed under: Uncategorized | 2 Comments »

In the Agile Project Management Processes Grid presented by John Stenbeck in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, the process that comes right after Process 1.1 Stakeholders Identification is Process 1.2 Vision Statement.

For reference here the four agile tools which are used in the process of defining and clarifying the vision for a releasable product:

1. Vision Statement (Process 1.2)–sometimes called an elevator statement, an uncomplicated way to define the product vision in a short statement
2. Product vision box–a tangible expression of a solution that includes whatever context is necessary to convey what the product will be
3. Product data sheet or PDS (Process 1.3)–one-page summary of key project objectives, capabilities, and information that convey how a project fulfills the product vision
4. Flexibility matrix–a tool that communicates how to handle trade-offs with a grid showing the relative importance of constraints such as scope, schedule, cost, and quality by defining them as fixed, firm, or flexible (only one constraint may be fixed)

The last post covered the second agile tool listed above, the Product vision box.   This post will cover the third agile tool listed above, the product data sheet, which just happens to be Process 1.3 of the Agile Project Management Processes Grid.

Product Data Sheet

This is a one-page summary of key project objectives, capabilities, and information that convey how a project fulfills the product vision.    According to author Jim Highsmith in his book Agile Project Management, Creating Innovative Products, the product data sheet provides the project information that the team and all the stakeholders need in an appealing, condensed format which constantly refocuses them on the strategic aspects of the project.

Here are the typical elements of the Product Data Sheet:

• Project Start Date
• Project Finish Date
• Agile Leader (the project leader who guides the process)
• Customer/Proxy (the project leader who guides the product)
• Elevator Statement (see previous blog post on this agile tool)
• Customer Segment(s)
• Customer Benefits
• Flexibility Matrix
• Milestone Table

Using the example I’ve used for the previously presented agile tools in the series, let me take the example of an app that is already in existence called Duolingo, which I use every day to study foreign languages.    The following is an example of a product data sheet which uses my own made-up content to give an example of everyone of the elements listed above.

You can see how the customer will be focusing on the elevator statement, the customer segment(s) and the customer benefits, whereas the team will be focusing on the flexibility matrix and the milestone table.    It is more left-brained and logical in its presentation as opposed to the more right-brained product vision box which is more visually-oriented and geared more strictly for the customer than for the team.

The flexibility matrix is used when making a decision about what features have priority and need to be developed first. I have saved an explanation of this last of the 4 agile tools for product development for the following post.

Filed under: Uncategorized | Leave a comment »

In the Agile Project Management Processes Grid presented by John Stenbeck in his book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, the process that comes right after Process 1.1 Stakeholders Identification is Process 1.2 Vision Statement.

For reference here the four agile tools which are used in the process of defining and clarifying the vision for a releasable product:

1. Vision Statement (Process 1.2)–sometimes called an elevator statement, an uncomplicated way to define the product vision in a short statement
2. Product vision box–a tangible expression of a solution that includes whatever context is necessary to convey what the product will be
3. Product data sheet or PDS (Process 1.3)–one-page summary of key project objectives, capabilities, and information that convey how a project fulfills the product vision
4. Flexibility matrix–a tool that communicates how to handle trade-offs with a grid showing the relative importance of constraints such as scope, schedule, cost, and quality by defining them as fixed, firm, or flexible (only one constraint may be fixed)

The last post covered the Vision Statement, which also happens to be process 1.2 of the Agile PM Processes Grid.   This post will cover the second agile tool listed above, the product vision box.

Product Vision Box

The product vision box is a tangible expression of a solution to that includes graphic images as well as narrative content to express the customer’s product vision.    This is meant to be presented to the customer so technical jargon is to avoided as much as possible.

One way to create the product vision box is to start with the vision statement, sometimes called the elevator statement, as discussed in the last post.    Let’s review the elements of the vision statement, as set forth by Geoffrey Moore in his book Crossing the Chasm.

Vision Statement

For:  [name a customer type]

Who Want:  [state a specific need or desire]

The:  [name your product]

Is a:  [name the product category]

That:  [name a compelling reason to buy or use the product or service]

Unlike:  [name the leading competitive products]

Our Product:  [specify the differentiating features or functions]

Here’s an example I created with an app that I use every day to study foreign languages called Duolingo.

For all those who want to learn a foreign language, the Duolingo app is an free app that can take you from having no knowledge of a foreign language to fluency by using it just 10 minutes a day, unlike other foreign language programs like Rosetta Stone that can cost up to hundreds of dollars and require a much larger time commitment.  Our product teaches the user the basic and intermediate levels of any one of a dozen or more European languages.

Vision Statement –> Product Vision Box

Here’s a sample of a “Product Vision Box” for the Duolingo app that I created using the vision statement.

DUOLINGO!

THE EASY, FUN WAY TO LEARN A FOREIGN LANGUAGE

For any one who wants to learn a foreign language

App can be downloaded to your iPhone or Android Device

Be fluent in months if you practice just 10 minutes a day

App is free to use

Learn any one of a dozen foreign languages, with more being added

GO FROM LANGUAGE ZERO TO LANGUAGE HERO!

As you can see, there is the product title, followed by a slogan which gives the basic function of the product.   Then you can include a graphic element which shows either how the product will work, or in this case, the logo that plans to be connected with the product, the owl named Duo.

Then the elements of the vision statement can be stripped out and given underneath.    I have followed the list with a catchy slogan “Go From Language Zero to Language Hero” which is aimed at the potential end user, who may have tried to learn a foreign language in the past and had little success.    This is obviously just an example, but it shows the approach being used.

Just remember that there are four communication preferences, those that focus on

• Ideas (relates to what people think)
• Process (relates to what steps people will take)
• People (relates to what people feel)
• Action (relates to what goal people aim for)

One of the perpetual communication problems project managers have is that they are usually have a primary strength in the process communication preference, but may not be able to communicate effectively in the people communication preference, which requires you to tell stories so that people can not just see the steps you are going to take to get to the solution (which is what the process communication preference emphasizes), but what the solution will feel like, look like.    The last statement in the product vision box was “Go from Language Zero to Language Hero.”   This is an emotional appeal to a user, not a practical one.    If you just want to learn a foreign language, then you should try this product.   But if you have been frustrated in the past trying to learn a foreign language, then you should REALLY try this product.    See the difference?    If you have graphic designers or someone with a visual bent, then that is the person you should be using to help create your product vision box.

For those who want to use an approach that is more along the lines of those with a preference for process-focused communication, then you should try the next agile tool, the Project Data Sheet.   That is the subject of the next post.

Filed under: Uncategorized | Leave a comment »