Mark Gibson; PgMP, PMP, IBM certified Executive Project Manager

Time and Materials Budgets: Who is responsible?

In my experience, project managers view Time and Materials Budgets in two separate ways: 1) the customer is responsible for containing the budget through scope, 2) the project manager assists the customer in maintaining both the labor and expense budgets.  Individuals are very passionate on either side of these schools of thought.  How many times have we heard, "It's time and materials, let the customer tell us what they want." or "It's time and materials, we will reassess budget after the requirements are complete."  Each of these statements assumes a non-agile model which is a separate discussion, but in my opinion is something the PM should reconsider.

In the first school, PMs proceed through the requirements processes and allow the customer to define the requirements without regard to cost containment.  In most instances, the end user community of the customer shoots for the stars and asks for more than they really need.  In some cases, they know the scope will be reduced and in others see how far they can push the vendor.  This leads to a situation whereby the available project budget has been exceeded, customer expectations are high, and the PM has to reduce the scope of the project to maintain a budget somewhere near the original because the end users do not have a mechanism to understand the cost of their requests.  An additional problem with this approach is an implicit assumption that the customer can afford any set of scope or that the customer is responsible for containing the aspirations of their end user community.  I find this to be true in only a small number of cases.  Taking this position can put the customer PM in an awkward position.

Given the customer technical resources must work with their end users over many years, they implicitly look to the vendor PM to maintain the scope within the budget as the requirements unfold.  This affords them the opportunity to be the arbitrator of any disputes and keeps them in a good long term position with their end users as they are perceived as looking out for the best interests of their users.  This school of thought also entails the vendor PM to identify and maintain a tally of the extra work the customer is asking for that is producing upward pressure on the budget.  By keeping the top end number in front of the end users, the customer PM can maintain a more appropriate arbitrator position while still maintaining the high level budget figure.  This also puts the responsibility for cost containment on the vendor PM as they will need to dynamically maintain a running budget figure while keeping a viable solution in place.  Typically this includes updating the customer PM on the cost of the emerging scope through a series of estimates.

In the end, responsibility for budget control is shared between both PMs on the project.  For vendor PMs who take the lead in containment with the customer, they will have a better positioned customer PM and a better relationship.

Basic tenants for Enterprise Project Management

For those medium to large enterprise projects, having a set of basic tenants that keep me focused has proved valuable to run the projects and to assist the project teams in understanding the basis behind decision making.  Each of these tenants is unique but also are used in concert.  These tenants are:

• Customer collaboration is the key to a better solution

In today’s Enterprise 2.0 environment, openness and the use of collective intelligence are proving valuable avenues to achieving higher levels of success.  This has been true in the realm of enterprise project management for some time as the methodologies that include early prototyping of either commercial or custom software embrace this concept vice the more documentation centric approaches that produce large and detailed requirements specifications.  In my experience, putting more working software in front of the customer sooner enables a better review of the proposed solution in a faster time period.  The end result is less requirements change and shorter delivery time periods which is the position we all want to be in.

This collaboration is especially true in the commercial software realm where the customer business processes are mostly molded into the processes defined by the software.  This affords the project manager an opportunity to build working prototypes of the software to both educate the customer on the software features and engage customer personnel on the most appropriate manner to configure the software.  This results at least in a solution into which the customer has more ownership due to participating actively in how it was configured as opposed to being told how best to configure.  Most technicians like to have creative license in these phases.  The same is true for the customer technical resources.

• Requirements will change during the project

When operating within the document centric methodologies, we all strive to develop requirements that are stable.  In the 80s and 90s, we developed metrics around this concept to understand the risk when the requirements change.  The one constant is that the requirements did change and always will. Any approach we take to requirements gathering is going to be imperfect so planning for this change both in the budget and schedule are crucial to project success.  Planning extra development capacity or planning an incremental drop with limited functionality so the project manager can add to it when the requirements change is something I try to always do.

• Statements of Work and all project deliverable are firm commitments

In most cases, project managers are given statements of work upon which to execute.  These documents are written and approved by people other than the PM or the project team.  In some cases, this can put the PM into a difficult situation when commitments stretch the bounds of the possible or in timeframes that stretch our capabilities.  In all instances, these documents as well as all documents developed by the project teams are firm and binding.  In my experience and in rare cases, these documents are considered guidelines that can be renegotiated at any time.

When these renegotiations occur, the customer trust in the PM is diminished.  The natural continuation of the theme is if this is not a commitment then what else is also not a commitment.  The degradation of trust becomes an issue when any decisions are made and most acute when the difficult decisions are made.  On my projects, I treat the SOW as a document as a firm commitment and use the project documentation to add detail to the commitments defined within.  For example, if the SOW defines custom functionality for creating and modifying purchase orders, then the requirements define the number of screens, the screen layout, etc.  The requirements would not attempt to remove the purchase order modification functionality.  This can occur when the effort estimates by the project team are greater than by the SOW writers and creates an atmosphere where the reduction in scope is justified by the differing estimates.  Resisting these temptations will go a long way to building and maintaining the trust within the whole project team. When requirements do change as stated above, the burden or proof is on the PM.

• Satisfy the Project Sponsor(s) to gain acceptance

One of the key time periods on any project is when the customer is determining whether to accept the project. The key decision makers should be identified early and are typically the Project Sponsor.  In my opinion, this is the person or persons who pay for the project and will use the results of the project.  In many organizations, this can more than one person such as a business sponsor such as a CFO for a financials project and the CIO for the technical aspects of the project.

Where the confusion lies is the day to day contacts on the project are seldom these individuals. They are individuals who work for and implement the guidelines defined by these individuals.  I believe it important for the project manager to stay in close contact with the sponsors and understanding their strategic goals and issues so the project can achieve these goals.  In my experience, if the project achieves the strategic goals it will be considered successful.  This is not to say the tactical goals of the project team and all the detailed requirements are not important because they are.  When choosing between achieving a tactical goal and either a strategic goal or undermining a strategic goal, I will choose the strategic goal unless I have the consent of the sponsors to do otherwise.

When the time comes to make the decision on the project acceptance, most sponsors will take the input from the project team but make the decision themselves.  If the project manager has maintained close contact with and met the goals of the sponsor(s), the acceptance decision will be much easier.

• Plan for the unexpected… It is going to happen.

In every project I have worked, unplanned work occurs.  The reasons for this are varied and typically unique to the project but it happens nearly every time so the project manager has to plan for the unexpected.  What happens is a change in the triple constraints: schedule, budget or scope.

Planning for these items comes down to leaving extra time in the schedule and budget.  In an incremental delivery model, keeping the final drop with less than a full team’s effort affords the opportunity to move additional functionality into that release.  This is akin to padding the critical path a concept on which many people have written.  In the single release models, the padding of the critical path is the mechanism for planning against unplanned schedule issues or increases in scope.

I typically try to keep 10% of the budget back for contingencies.  Operational managers have historically used this concept for unplanned work as well.  The same concept applies well for the managers of projects.  The extra money can be used to increase staff to cover unplanned losses of staff, increases in scope, clarified requirements that increase effort, increases in actual effort over the original estimates, or even to pay for change requests.  The use for change requests has the added benefit of maintaining the original budget when the project team or sponsor receives unplanned requirements or changes in company policy impact the project.

In concert with tenant #1, I am completely open with my customers on this concept and collaborate with them on if or how to use the additional funds.  In the rare instances when the contingency is not used, the project is under budget which is a good position in which to be.

• Do what you say you are going to do.

This tenant seems like common sense but we all know common sense is not common.  This applies to even the small things such as accepting meeting requests, being on time for meetings, and publishing deliverables on time. For traveling consultants, this includes being on-site when agreed, not missing flights, or planning for flight delays.  In all too many cases, consultants use airline schedule and delays as reasons for being late to work.

This also applies to deliverables such as meeting all the requirements in a SOW or requirements specification, conducting scheduled design reviews when and how agreed.  The word of a PM should be sound and unwavering.  What we all know is that projects are built with many interdependent activities and the commitments we all make.  The plans are all built on these activities, commitments, etc so the plan and therefore project breaks down when we do not do what we say we are going to do.

When the difficult project decisions arise, I keep these tenants in mind and they both drive the decisions and make them easier by focusing me on what is truly important.