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.

Presentation Tips: An article from "The Daily Muse"

This article written by John Neffinger and Matthew Kohut and published in "The Daily Muse" is an excellent definition and description of Presentation tips.  The tips deal with body language and how this language impacts the presentation.

Analyze or Gather Requirements.. What's the difference?

For many project managers, these terms are synonymous and entail those activities in certain models that occur at the outset of the project whereby our project teams write a requirements specification.  Personally, I am not a big advocate of documentation heavy implementation models but understand these models remain prevalent in today’s projects.  So what is the difference between gathering and analyzing requirements?

In my opinion, gathering entails that set of activities whereby customers are asked to define their requirements including that set of needed capabilities, interfaces to existing systems, reports, etc.  In a nutshell, the project team is told the set.  When analyzing requirements, the project team listens to how the customer runs their business before distilling the conversation into a set of business needs.  In a nutshell, the project team analyzes the business operations and defines the requirements vice being told (gathering) the requirements.

Clearly in either situation, the customer will ultimately agree upon these requirements so neither activity is not completed in isolation. Typically, what I have found is many business users if asked to define their requirements will actually tell the project team how their current system works.  How many times have we heard the phrase, "my current system works this way", or "this is how I do it today."  What the users typically describes is that set of key strokes or data entry that occurs within the current system.  This approach will necessarily include how screens function, what reports are required and is not necessarily what the new system capabilities should be but what the old system does.  Especially with a commercial software implementation, gathering requirements sets the customer expectation the new system will work like the old system.  This leads to extensive customization of the commercial software, force fitting business processes vice optimizing them and rarely leads to a new system that is an improvement on the old system (the reason for the project).

In the situation whereby, the project team analyzes the requirements, the old system context is not set as an expectation but rather that some business processes will change and will improve the business situation.  When the customer leads with "My current system work this way," the project team should probe deeper and ask the why questions to understand the true business requirement/need.  This affords the project team the opportunity to model the business processes within the core capability of the commercial package, minimize customization, and ensure the strategic objectives of the project are met the most important of which is an improved business situation with the new system.

To illustrate the point, I recently had a customer who during the requirements phase was defining the required data elements for a screen including screen operation.  They were describing how their current system operated.  The system was a service ticketing system that required a screen to input service tickets, another to modify tickets, a third to review tickets resolutions, and they needed three reports to manage the business.  Clearly, they were defining a detailed design based on the existing system.  To distill the requirements, I asked a couple of pointed questions.

Why do you need a screen to analyze tickets?

Why do you need a separate screen to modify tickets?

What are the purpose of the three reports?

By asking these questions, I determined the customer uses an outside vendor to service the tickets and this vendor is paid for each resolved ticket.  The three reports were currently used to support the invoice review process and were three different cuts of the same data.  In this situation, the project team now understands the business to a deeper level and has greater flexibility in not only improving the business but providing a solution with minimal customization.  In my instance, I combined all the screens together as this is how the commercial package works and provided a single report in the form of a pivot table that provided the customer an easier way to review invoices as well as an electronic record of the reconciliation process which eased the negotiation process when differences of opinion occurred.

In my opinion, project teams and especially commercial software project teams should always analyze the requirements vice just gathering them.

Can Project Managers operate on an Island?

As project managers, we are routinely the only project manager from our company on the project or are an independent.  In these scenarios, we are virtually alone when managing a project except for potentially a customer project manager and certainly a project sponsor.  The customer relationship has a certain dynamic that is different than with resources from the same company as the communication channel can become cluttered by contracts and desired customer relationships defined by the contract or services organization.  These dynamics can leave the PM on an island with the project.  If we use an analogy of a person actually living on an island, there is a life line back to civilization.  This can be a boat to travel back or a radio/phone to communicate when difficulties arise that are beyond the capabilities to handle on this island.  Is a similar lifeline needed for project managers?

Seasoned project managers have a wide variety of tools and skills to handle a vast majority of situations.  These situations can be technical where a commercial product is not functioning as designed so the vendor product development organization (PDO) is engaged to correct the issue(s).  A customer may request new functionality not yet in the product necessitating engaging a vendor product management organization to assess the feasibility of an enhancement.  The issues could be staff related where individuals are not meshing well with their counterparts or need additional seasoning in technical or consulting skills.  There are many scenarios in which the PM must enlist assistance outside of the immediate project team to succeed in project delivery.

When these scenarios do occur, the PM needs to have both open communication channels to the outside entities and a path of escalation when conflicts arise that exceed the PM's capability or authority to resolve.  On the customer side, a project sponsor usually assumes this role and in a independent situation may be the only avenue open to the PM.  When dealing with a commercial vendor, other avenues need to be open.  In some cases, the sales or account executive who made the sale can and should be kept abreast of issues and available as an issue resolution asset.  Additionally, services delivery executives should have an open communication channel with their PMs so the PMs have both a sounding board and an avenue to resolve potentially "sticky" situations.

In many services organizations, the PMs have little negotiating room when issues arise and have financial implications.  As any business, a services organization has revenue and margin targets to meet and the PM is on the front line to achieving these goals.  There are times when concessions in these areas may be the best resolution to an issue.  When PMs do not have negotiating authority for finances, their credibility and authority is diminished in the eyes of the customer.  The same applies when staffing issues arise such as an underperforming resource or resource who is not getting along with the others.  When PMs have this authority and the support of their management, the chances of success greatly increase as the customer sees them as their single point of contact and issues are resolved more quickly.  In too many organizations, this authority rests with the services managers for various reasons and this dynamic undermines PMs in the field.

Project management is a difficult profession with many challenges faced each and every day.  In most instances, the PMs are comfortable operating in this fashion and should to be effective in the role.  As with a person living on an island, the PM needs a life line when circumstances occur that are beyond either their capabilities or authority to resolve.  Organizations that grant the PMs more authority in the field will experience both more successful and happier project managers and customers; and fewer instances where services managers need to be involved in resolving "sticky" issues.

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.

Engaging Project Managers in Pursuits increases project success

The end of every software pursuit cycle marks the beginning of a software project delivery.  Naturally, this assumes business software that has an associated implementation and is at some level, obvious.  The transition between the software sales team and the delivery team marks a time of risk to the organization who just made the sale.  The software team has spent significant time building the relationships and trust in order to close the deal.

This relationship and trust are typically a significant component in making the decision to move forward with both the project and the delivery organization.  The sales team is likely a very different set of people than the delivery team.  The relationships built with the sales team do not yet exist with the delivery team and there is no certainty the individuals on the delivery team will succeed in building the solid trusting relationships needed to successfully complete a project.  This increases in importance with the complexity or size of the project as well as the real and perceived project and business risk.

In order to kick start this relationship building, many but not all services firms have a transition where the sales team briefs the delivery team on the key project drivers, people, personalities, project advocates and impediments, and goals and objectives.  They may also have a kickoff or meet and greet meeting where the sales team introduces the delivery team.  These initial meeting even if held face to face pale in comparison to the weeks and even months the sales team has used to build effective and solid business relationships.

In addition to the relationships, the sales team has a wealth of knowledge about the customer that is important information for the project manager to have.  The sales team will attempt to convey this experience to a delivery team in a matter of minutes or hours.  At best, this is a very difficult endeavor and assumes nearly perfect consumption of the information delivered.  Services management can mitigate the consumption by producing a written report and briefing this "transition" report but this report can take more time to produce than is desired given the volume of data.  This leads to the question about how to affect a transition between the sales and delivery teams to ensure the maximum probability of success.

This approach has merit and may be the only option available to services firms.  Any transition meeting does not address the relationships built by the sales team.  Relationships are between unique people and one on one connections.  These relationships are only built by interpersonal interaction and ideally face to face.  What if we did not have a transition but involve the delivery team leadership in the sales pursuit?  Perhaps, the project manager and the lead architect become involved in the sales pursuit while the scope, estimates, and statement of work are under construction. This could have the following benefits:

• Delivery team is involved in the estimates so has a greater sense of ownership in those estimates including the project schedule that falls out.  They would also understand any underlying assumptions having been involved in the process that defined the assumptions
• Delivery team would understand the scope including areas of client sensitivity.  This would eliminate the delivery team from having to ask the questions but also having been in the meetings when the decisions were made are now able to negotiate during delivery from a position of knowledge having been there.  A secondary benefit is not having to involve the sales team when questions about sales pursuit decisions arise freeing the sales team for their next pursuit.
• Delivery team could build relationships with the customer key resources in a time when scope, schedule, and budgets are being defined and contractual commitments made.  As we all know, these discussions are more difficult during delivery as project constraints have already been defined.  During a sales pursuit the constraints are not yet defined so the environment in which to build the relationships is more conducive.
• The need for a transition disappears as the delivery team gets the transition during their efforts in pursuit.  The transition duration is now measured in days and weeks enabling additional discussions including risk identification to occur during the pursuit, relationships to build naturally over time and project risks incorporated into the Statement of Work (SOW).
• Project managers have the opportunity to assess the appropriate implementation and development models achievable by the customer and mitigating any associated risks during the pursuit versus addressing after SOW approval.  Fundamental model changes may need SOW revisions and approval so can heighten tensions with the customer as well as cost and schedule risks.
• Project managers have the opportunity to assess and define fundamental project processes like issue and risk management, source and document control, and test management as examples.  The definition of and gaining consensus on these processes can have a profound impact on both the project budget and schedule as well as the appropriate implementation model.  Having a seasoned project manager make these assessments and carry the processes forward into the project enables a services organization to incorporate these processes into the SOW or resolve fundamental process issues before the project start.
• Software service firm executives can also assess the progress of relationship building during the sales pursuit and make staffing adjustments prior to any customer issues arising instead of during the project when tensions are higher and the services firm is more likely to adsorb cost and schedule variances attributable to less than desired relationships.

During sales pursuits, services firms face a systemic question about involving delivery staff in the sales pursuits.  The questions of utilization typically come to mind as well as the skill set of delivery staff during a pursuit and keeping focused on the pursuit and not delivery.  There are risks both to including the delivery staff and not including them.  Services firms should consider including at least their project managers in the pursuits and training the project managers in the differences between selling and delivering.  When a firm can accomplish this, the advantages defined above can add to the successful completion of a firm and differentiate those firms from their competitors.

Many firms may also consider using delivery management or sales engineers to attempt to accomplish these assessments but this approach does not address the other benefits.  The skills needed to make these assessments typically only reside in project managers with field experience.  Others may have some capabilities in this area and only in very rare cases do these other roles have the needed skills, knowledge, and experience to effectively make the assessments.  The project manager who will manage the project is the best resource to make the assessments, build the personal relationships, and be well positioned for any discussions around decisions made during the sales cycle.

Implementation Methodologies: Good or Bad?

Are implementation methodologies helpful to project success or a hindrance?  It depends on how the project manager executes the methodology, and adapts to the unique situations on each project, and how well the project conforms to the assumptions within the methodology.  I am a firm believer in the value of an implementation methodology having used them previously and developed several myself.  The methodologies are a good starting point for developing a project plan providing the project manager with:

1. Templates for all project deliverables that the consulting/contractor staff are familiar with thus eliminating the startup costs associated with training the team and agreeing internally on the format and content of deliverables.
2. A development methodology the staff is both trained in and is comfortable executing.
3. Checklists of tasks to consider within the context of the project.
4. Typical staffing profiles and associated task durations and dependencies.

These are just a few of the benefits of a methodology and all have a positive impact on project success.  These methodologies are also based on fundamental assumptions that many times get missed by project managers including:

1. The customer is familiar with and agreeable to the development model proposed.
2. The customer can support the customer staffing model with roles such as a  business analyst, testing leads, etc.
3. The customer is agreeable with and supportive of the set of deliverables defined.
4. The statement of work or project charter is compatible with the methodology.
5. Individual projects should adjust the tasks, durations, and staffing to fit the unique project needs.

The specific assumptions associated with each model are unique to each model so identifying the implicit assumptions inherent with any methodology becomes a key component in determining how to tailor the methodology to each unique project.  In my experience, few methodologies formally document their assumptions creating a situation whereby PMs must derive the assumptions.  The tailoring concept is also a key as we all know that each project has its own idiosyncrasies that we have to deal with.  When methodologies are treated as a “cookbook” and applied in the exact same manner for each customer, then they can be a detriment to the project.

By understanding the implicit assumptions behind a methodology and tailoring the methodology when 1 to all of these assumptions are not valid, the project manager can effectively leverage the strengths and mitigate any weaknesses of a methodology.