Creating a contract for work done in an Agile environment

March 5, 2011
3 Iterations of Agile Development Framework

Image via Wikipedia

I’ve been talking to some colleagues lately who do consulting work, usually software development, for various companies.  Typically, they have been engaged by clients in traditional (or “waterfall”) projects, where they provided specific functionality that met specific quality criteria and had to be completed according to a specific schedule.   In return, they received an agreed-upon compensation.

These types of projects were relatively easy to estimate, bid, and negotiate with clients because all of the deliverables (content, schedule, and quality) were fixed in advance.

However, as more and more of their clients are wanting to have their projects developed using Agile, their traditional types of software contracts simply don’t work.

One of the fundamental aspects of Agile is that a small amount of the work in the total project is performed in a short time period, or sprint.  Each sprint lasts 2-4 weeks (on average) and the content for each subsequent sprint is identified in part by determining how well (or poorly) the already completed work meets the customers’ needs.  Thus, if a certain bit of functionality is developed in a given sprint, it could be modified significantly (or even re-done completely) in one or more subsequent sprints.

Thus, it is possible for a client to spend so much time refining and “polishing” work that has already been completed, that the overall duration of the project extends far, far beyond the original target completion date.    And as you can appreciate, the client doesn’t typically offer additional compensation to the people doing the work — arguing that the work should have been done “properly” in the first place — although it’s not clear how anyone could have done the work “properly” when the client didn’t know what they wanted in the first place.

It’s clear that the Agile development methodology is not going away — its advantages are too great to ignore.   So we need to modify the contract language we use to engage consultants accordingly.  Otherwise, consultants will either go broke attempting to provide the “free work” required by ever-changing functionality or will simply refuse to perform work in an Agile environment.

Here’s what I think…

In a software project there are only 4 variables — (1) the content being provided, (2) the schedule for the delivery (or deliveries), (3) the quality that is achieved, and (4) the resources that are deployed to do the work.   (Note:  Cost is an attribute of a project, not a variable.)

Thus, if a contract is going to embrace Agile development concepts where (a) the project’s content is allowed to change frequently to accommodate re-work, (2) the project has to achieve a specified level of quality, and (c) the project’s schedule must adjust to accommodate any re-work — the ONLY variable left is “the resources that are deployed to do the work”.    And since every resource contributes a certain amount of effort to the project — the contract must specify a certain amount of work (or “hours”) that the client is paying the consultant (or consulting organization) to perform.

This type of contract is not especially attractive to a consultant because it is too transparent.   A potential client can easily identify the hourly rate for different consultants and compare them with rates from others.  Thus, “premium” consultants (or consulting organizations) must provide additional justification on the “value” of their services — which is often not easy to provide in a convincing manner, especially in difficult economic times.

In some cases, clients are also not as comfortable with this type of contract — because it makes it difficult to justify continuing to do business with a long-established consultant (or consulting organization) when it becomes obvious that their hourly rates are significantly more than those of other potential providers.

However, as more and more contracts are written with Agile development in mind — consultants and their clients will become more comfortable — just as development teams have increasingly embraced Agile in recent years.

So, if you are a consultant I urge you to develop a contract where you get paid on an hourly basis soon, so that you are well positioned to bid opportunities for Agile projects.  And if you are a company that employs consultants for Agile projects, I encourage you to request contracts with hourly labor rates, so that you can optimize the quality of your projects.


Documenting Requirements — the Tools you will need to be successful.

November 2, 2010

I wrote previously about an approach that I have used to manage requirements.  Subsequently, I have been asked to elaborate on the tools and rationale, so here goes…

As previously discussed, “requirements” consist of a wide variety of inputs from numerous internal and external stake holders.   Yet all requirements suffer from 2 problems — (1) It is impossible to address all of your open requirements in a given software release, and (2) things change.

So, that very carefully defined requirement from that key customer that was documented in year 1 may be significantly different from what that same customer needs in year 2 (or year 3).  You obviously don’t want to spend time developing something that doesn’t meet a business need and you also don’t want to lose any of the knowledge about that requirement that you have collected from this customer (and others).  Lastly, if you are going to reconnect with a customer to review the details of a particular business need — you MUST have a good understanding of what they have said before — or they will dismiss you as a waste of their time — which is not helpful on many fronts.

In other words for every requirement, you need some method to gather, track, and maintain its “definition” and the features that you will need to address it over time.  A document management system (such as Alfresco) is an ideal tool for this purpose.

You may ask — “but why not use a source code control system like Subversion or CVS?”   The simple answer is “they are not the right tools”.   Source code control systems are designed to help multiple people work on source code files that often overlap with one another.   Thus, these systems have sophisticated tools for identifying the differences between two versions of the same source code file and allowing them to be merged together.  In my experience, these tools do not work with documents — especially Microsoft Word documents — and can even corrupt the formatting and content in some cases.  In addition, source code control systems typically require each user to maintain a local content repository that must be synchronized on a regular basis to ensure that each user is always looking at the most current copy of a document — which is counter-intuitive, at best, for most non-Engineering personnel.

By contrast, a document management system is designed for editing, sharing, and managing “documents”.  It uses a simple check-in and check-out model that allows users to view any accessible document but requires all updates to be done using an exclusive write approach.  A document management system also provides tools for managing the maturity of each document so that preliminary feature ideas can be shared with some people and more mature feature definitions can be shared with others.   (Have you ever had a situation where a very early version of an idea was sold to a new customer by an overly aggressive sales person?  If so, then you should appreciate the ability to control when requirement and feature information is shared with different audiences.)

In other words, a document management system is the best tool for “managing documents” whereas a source code control system is the best tool for “managing source code”.  (Apologies if this seems redundant.)

You also need a method to plan a software release that will (hopefully) include numerous features that each address one or more requirements.  You need a method to select which features will be included in each release and a way to obtain estimates from Engineering on what it will cost to develop each feature.  You also need the ability to iterate the definition of each release numerous times — adding or subtracting different features — trying to get the “perfect” balance between features, schedule, and Engineering capacity.

You also need to capture all of the assumptions and dependencies that Engineering identified while creating their estimates for 2 very important reasons:  (a) Engineering spent time (and money) creating these estimates and if a particular requirement isn’t addressed now, it may be later.  You don’t want to pay twice for the same thing. (b) If you know how each estimate was derived, you are much more able to verify previous estimates or anticipate problems with current estimates, based upon$ its assumptions and dependencies — even if your Engineering personnel change over time.

You could plan each software release using a spreadsheet — but why would you want to?   Do you really want to continually update the spreadsheet, circulate it to numerous internal people, and then consolidate all of their inputs?   And even if you want to operate this way — do you really have the time?  Or are you assuming that you will get each release planned perfectly the first time?

This is where an issue tracking system (such as Jira) can (help) keep you sane.  You can use a field (such as “Specification”) to include a link to the relevant requirements document within your document management system.  You can use another field (such as “Target Release”) to designate the features that you want Engineering to review and have them include their estimates and assumptions in other fields — based upon the information on the feature and its underlying requirement(s) maintained in your document management system.  So when you generate a report (or Excel export) for a given software release — you will be able to immediately determine whether you have under or over defined the release based upon your Engineering capacity.

You are almost done — all you need now is a “plan” for this release.   If you are using the waterfall method, I suggest creating a project plan with Microsoft Project using the feature, dependencies, and estimate information from your issue tracker.   Update it regularly (I suggest weekly) and provide copies to all team members.  (I suggest using a PDF print driver so that you can easily share the project plan with everyone without requiring them to have access to Microsoft Project.)

If you are using Agile, I suggest using the GreenHopper plug-in for Jira — or something similar — to plan each sprint.

That’s all for now.  I hope this has been helpful.   As always, comments or questions are welcome.

How productive is your software development process?

April 23, 2010

Do you wonder how productive your software development process is?

Do you wonder whether an Agile or Extreme Programming approach would increase your development productivity?

Are you worried that your job will be outsourced because your company wants to increase your development productivity?

Wouldn’t it be wonderful if you could actually know the answer to these questions, instead of having to guess or rely on opinions, theories, or experimentation?

I recently had an opportunity to attend a Nashua (NH) Scrum Club meeting where Michael Mah from QSM Associates ( gave a presentation on tools and techniques that his company uses to accurately measure the productivity of a software development process AND to compare the productivity of a project to the industry average for similar projects being done by similar teams.  It seemed almost like magic.

First a bit of background…

I have always thought that any software project consisted of 4 key characteristics or dimensions:

  • People — The number of people who are involved in the project.  This includes everyone who contributes to the development, testing, building, integration, and management of the project.
  • Content — The number of  features that will be included in the project.
  • Schedule — The schedule, or completion date, for the project.
  • Quality — The level of quality that must be attained by this project.

And while you may wish to optimize all of these dimensions for your project, the relationship between them is absolute.  So if you optimize one dimension, another dimension (or two) must be changed to compensate.

We have all seen this in practice.  As an example, consider that recent project where it was on schedule, until a key customer insisted that you add “just a few more critical features”.   For some strange reason, the project then finished later than planned.   And people were surprised.   Wow !!

Now, let’s look at the magic that QSM can do with the same information…

It turns out that QSM refers to these 4 dimensions using slightly different terms, as follows:

  • Effort — The number of people who are working on the project.
  • Produced Software Size — The number of “stories” for which software was produced, or the content of the project.
  • Duration — The duration of the project.
  • Discovered Defects — The number of defects discovered during FQA (Final Quality Assurance), or the quality of the code that was produced.

However you can still accurately determine values for these 4 dimensions and use them to calculate the productivity of a software project.    So when this information is entered into QSM’s software tool, it generates a series of graphs that compare the productivity of your project to other projects with a similar dimensions.   (Please see QSM’s web site for more information.)

This allows you to accurately and reliably analyze the productivity of your project AND to compare it to other similar projects.  So you can also predict, as an example , whether it is (or is not) a good idea to move some (or all) of your development team off-shore.

And in today’s environment, where your products need every possible competitive advantage, wouldn’t you prefer to find out this type of information without experimenting?

Should Product Managers have a PMP Certification? — Part 2

April 20, 2010

My first post on this subject (Should Product Managers have a PMP Certification?) generated a lot of discussion and some very good ideas that were new to me.   Thanks to everyone who contributed.

Unfortunately, nearly all of the comments were left within various LinkedIn groups which limited the ability of people in other groups to participate.  Whoops — not what I had in mind.

Therefore, I thought I would summarize the thoughts from all of these groups up to now to help facilitate the discussion.  Apologies in advance for any editing mistakes I made and the names have been withheld to protect the innocent (or is that “the guilty”)…

Pragmatic Marketing Alumni Group

From Steve, a Global Product/ Project Management professional with a PMP

I got a PMP certification recently to understand what it involved and how it related to product management. It can’t hurt to get a PMP, but recognize that a PMP focuses on projects (schedule, budget, scope) , not products (technology, business, market).

The product management profession needs a certification program equivalent to that provided by PMI. PMI is 41 years old. It took over 17 years for PMI to create the first version of the PMBOK (Project Management Body of Knowledge), the basis of the PMP certification. Over that time they helped to establish project management as a recognized profession and fueled a tremendous market for an entire army of project management training vendors that did not exist before PMI was founded.

Product Management needs its own Product Management and Marketing Body of Knowledge, its own certificate programs, and its own equivalent continuing education (PDU) program. I believe the nearest equivalent to PMI for product management is the AIPMM – the Association of International Product Management and Marketing

The AIPMM is only 12 years old but is following a track similar to PMI to make Product Management a recognized profession. I believe they can create an explosive demand for Product Management training programs that will significantly expand the market for training vendors like Pragmatic, Blackblot, Pivotal, etc. Thus, AIPMM is an enabler for these vendors, not a competitor.

I intend to become actively involved in AIPMM. I recommend you and anyone else interested in making Product Management a recognized profession do the same. You should check them out. (

Boston Product Management (BPMA) Group

From Steven, Author

Certification is not needed. BUT, product managers must know how to manage projects + tools, terminology, etc. Taking 2 days PMP training should be sufficient. However, nothing beats real experience. Try using project management techniques to plan and manage a product launch. Works wonders!

Product Management (LinkedPM) Group

From Yves, VP Business Development and Senior Product Manager

I was faced with the same dilemma. I appreciate you raising the question, as I would like to hear other product managers’ point of view on the topic.

The way I solved it for myself was by achieving the following two things:

First, I received the NPDP (New Product Development Professional) certification from PDMA (Product Development and Management Association: which focuses on Product Management while encompassing some aspects of project management.

Similarly to the PMP certification, (1) one must demonstrate a fair amount of on-the-job experience, (2) one must hold a bachelor’s or higher university degree, (3) and pass an exam (at the time I passed it, there were only 300 NPDP certified professionals worldwide).

Thereafter, in order to maintain the NPDP certification, ongoing activities are also required; Activities that are related to product management that is, not project management. This is where it makes more sense for us, product managers, as you do not have to be a full-time project manager to maintain your certification. You can focus on your product management profession.

Second, I also obtained a Master’s certificate in IT project Management from George Washington University. The core curriculum of the program addresses all ten areas of knowledge tested in PMI’s certification exam.

As you mentioned, when working for small companies, a product manager often ends up playing the role of project manager as well, which is why I think the second certification comes in handy. It also lasts for life. It is a nice credential to add to one’s curriculum.

Creative Product Managers Group

From Chirag, Product Manager

I agree with your view of PMP certification as a “nice-to-have”, and not as a “must-have” or a “should-have”.

280 Group:  Product Management & Product Marketing

From Joe, VP Product Management

My recommendation is that Product Managers be aware of Program Management tasks and issues, but that PMP Certification is not required. I feel that you can learn about these tasks and issues without being certified. My gut feeling is that rather than getting certified, a Product Manager would be better off spending the time and effort developing market/problem analysis skills.
My unscientific crystal ball also tells me that if a Product Manager has an official PMP designation, that the company may be inclined make the Product Manager responsible for Program Management deliverables.
My experience is that Product Managers often fill a vacuum and perform Program Management functions. However, nothing comes for free. The time and effort required to make sure that resources are properly deployed and aligned often takes away from the Product Manager’s ability to analyze problems/market opportunities and then communicate the results of that analysis throughout the organization.
But in today’s market, the ability to multitask across a range of disciplines can differentiate you from the masses that respond to each Product Manager job posting.  A PMP Certification is a shorthand way of letting resume screeners and hiring managers know that you have certain knowledge and skills.
So if you have the time and resources, I feel that a PMP Certification can help you get a Product Manager job, but that the certification itself isn’t necessary to be a good Product Manager.

From Bob, Product Management, Business Development, and Acquisition Integration

I agree with you both. PMP would be nice to have and could assist in landing a job. I have found myself often project managing as SOP.

From Avijeet, Principal Product Manager

I am PMP certified and would agree with Dean that it is difficult and time-consuming to get PMP certified. The certification just shows that the incumbent has a practical understanding of project management best practices. A product manager need not be PMP certified, but he or she should be able to understand what various project management plan/budget versus actual metrics mean and initiate necessary discussions at right time.

Although a product manager does not have authority to initiate or scrap a project, but he will definitely be held accountable, if he or she did not bring up the new initiatives and changes to current projects at right time. The knowledge of the math that goes behind knowing this right time would help a product manager to work with project managers much more smoothly and successfully.

In summary, PMP certification is not must, but knowledge of project management best practices would be a critical success factor for a product manager.

Internet Product Management Group

From Randy, Managing Director

I think you could think of it this way —  What is the down side of getting a PMP when you are a product manager?
I don’t see one that I can think of.   It adds to your value proposition and may help you land a job.


It seems these days that more and more companies due to the down turn are looking for Product Managers to also assume PM task.
I am a big believer in Face time with clients, but companies are at skin and bones to make a profit, so they think that is a good way to merge talents.
Another fact of the matter is a lot of management and people in general don’t truly understand the role of a Product manager, and seem to blend it with PM work all the time.
You could be right adding a PM might make you do more work, but in tough times be glad you are working that much.

From Craig, Principal Consultant

I am often asked to take on PM responsibilities to the detriment of my product management role. One disadvantage that you did not mention is the inherent conflict of interest between project and product management. The former needs to focus on meeting deadlines while the latter needs to focus on the customer and their needs. As a product manager at heart I find myself constantly balancing feature creep with meeting my timelines. That said, while I am an advocate of keeping these hats on different heads, it does make you more marketable in todays’ job climate to bring more value to your employer through versatility.

My Conclusions:

  1. Project management is a necessary part of being a good product manager and you can’t be effective without a good understanding of project management tools and techniques.
  2. Having a formalized project management certifications (PMP or similar) is a good way to demonstrate your project management proficiency, but is not a necessity to being a good product manager.
  3. Devoting too much time to project management can detract from your primary role as product manager — which could seriously impact your product and your company.
  4. Some employers seem to be unclear about the differences between project management and product management, or they try to save money by combining these two roles into a single position.
  5. It is certainly desirable to have a formal product management certification (of some type).   And it would certainly help promote the distinction between project management and product management, as well as help advance the product management profession, if there was a well-recognized product management certification program that was utilized by many product managers.

Thanks to all who have contributed so far.

What do you think?  Have we captured all of the key elements?  Or are we missing something that you think is important?

Should Product Managers have a PMP Certification?

April 19, 2010

I have been thinking about software Product Management and the value of having a PMP certification for a while.  So I read the following post by Bernadette St John with interest.

How I See the True Value of the PMP Credential

She makes some very good points about the value of the PMP certification to project managers, but I still wasn’t sure whether software product managers, like me, should be certified.

Product managers spend (or at least should spend) a fairly large amount of time visiting and/or interviewing customers and prospective customers.  After all, you need to understand what your target market expects (or wants) if your product is going to be successful.  You also need to spend a fair amount of time with Development to make sure that they understand the requirements for your product.  Otherwise, they will not be able to work as efficiently as they should and you will waste precious Development resources.

And of course, there are all of the “other” consumers of your time:

  • Announcements, reading, and other research about your target market.
  • Announcements, rumors, and/or information regarding your competitors.
  • Sales people who need your help to close that big deal.
  • Marketing people who want to ensure that they describe the product correctly.
  • Technical support people who must be aware of the new product capabilities.
  • Consulting or implementation personnel who need to prepare to install (or customize) the new product version.
  • Documentation personnel who need to explain what the product does and how it should be used.
  • etc, etc, etc.

All of these efforts could easily consume 100% of your time.  So, do you really have enough time to “manage your project” also?

In a small company, you don’t have any other choice, because you are responsible for getting the product out the door.  It must have the right content, have appropriate quality, and be delivered to an agreed-upon schedule.  In essence, you often MUST be the project manager for the release — there isn’t anyone else — especially if the company is large enough to have multiple products, each with their own release cycle.

In larger companies, especially those where multiple teams contribute separate, but related, portions to each release of a large and complex product,  a separate project manager function often exists.  Thus, the product manager is responsible for managing their team’s deliverables, but is not generally responsible for the entire product release project.

It seems obvious that a product manager must also be a good project manager to be successful, but it still doesn’t answer the original question about PMP certification.

A PMP certification requires you to fulfill three requirements:  (1) a fair amount of on-the-job experience, (2) a certain amount of formal training, and (3) passing the certification exam.    And as Bernadette points out, ongoing activities are also required to maintain your PMP certification.

I believe that any good product manager could complete the formal training and pass the exam.  I also believe that you could successfully meet the on-the-job experience requirements.  However, once you get your PMP certification, which of your activities as a product manager can be reduced to allow you to fulfill your ongoing PMP activities?  Or would you simply work longer each day?

My conclusion is that software product managers should consider a PMP certification as a “nice-to-have”, and not as a “must-have” or a “should-have”.   There are already enough demands on your time and you are already forced to make compromises that impact the quality of your product.

So, if you are reading this, have your PMP certification, and have been able to maintain it over time — congratulations.  However, if you have been (like me) considering getting a PMP certification for a while, I suggest you put those thoughts aside and make plans to visit one additional customer (or prospect) instead.  It’s a better usage of your time.

%d bloggers like this: