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

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.

Program Manager Role in License Sale

In course of selling commercial software, there will inevitably come a time when a potential sale begins to slowdown or even  stall.  This can occur for many reasons including:

1. Uncertainty of internal risks of large project
2. Uncertainty of load of project on internal staff
3. Uncertainty of how project tasks are inter-linked
4. Uncertainty if vendor is capable of successfully completing the project
5. Uncertainty if services staff understands the business and can model the business within the tool

For a IT executive, these items can slow or even prevent a software sale.  A Program Manager can help by briefing the executive staff on these items or any other concerns expressed by the prospect.  The software sales team can leverage the Program Manager in this capacity to close the sale as the Program Manager can build confidence within the prospect that is difficult for the sales team to achieve.

Given this opportunity in my past, the following item have helped me.

• Brief an implementation/development methodology including key decision points and risky aspects of the implementation

Whether the project is a commercial software implementation, custom development project or any combination thereof, the PM can begin with the overall approach to the project.  Start with a template or shell project plan and define the major phases including the major objectives and activities in each.  Keep the conversation at a high level and focus on the flow of the activities and their relationship to the project objectives.  The staffing needs, key decision points, and risks will naturally fall out of the discussion.

Identify the activities where deliverables are produced and where intense business involvement may be required.  The initial requirements gathering sessions are a typical example.  Describe how these activities have been conducted in the past, highlight and stress the interaction between the vendor staff and the technical and business staff of the prospect.  This reiterates the consultative nature of the activities and that the prospect will drive the end product.

• Focus on the non-technical aspects of the project including communication, training, testing, risk management, and change management

In my experience, many of the concerns come from the non-technical areas of the project and include: How will we manage change?  Will we come in on time and within budget? How will we ensure the prospect staff is trained and able to operate the solution once built?  How will the solution be tested?  How will data be converted from the legacy systems?

Walk the audience through the project plan template and highlight these areas in a separate discussion from above.  This will demonstrate the completeness of the template, sensitivity to the long term operation of the solution, and and also enable the audience to focus on individual areas of concerns outside the context of the technical aspects of the plan.

• Present multiple options for business related issues without committing

Always present multiple options for consideration as the options will be discussed and that decisions are made during the requirements and design phases of the project.  Attempting to make them in this timeframe is premature until all topics are thoroughly discussed.  Having multiple options to consider demonstrates an overall understanding of the industry and that the project may uncover additional business improvements not previously identified by the prospect.

• Present business examples directly related to the prospects business and how they were solved previously

In preparation for the meeting, work with the sales team to understand and identify multiple business examples from the prospect's current environment and that are relevant to the project scope.  The audience will relate much better to examples from their business rather than more general examples. If there are no known examples from their business, keep all the examples within their line of business as a retailer will likely have difficulty relating to a business example from a financial services company.

When presenting the business examples, focus on the solution to the problem and ideally the conditions under which the decision was made.  This helps the audience identify the problem solving and consultative skills of the Program Manager and how the teams will interact during the implementation.

• Explain the rationale behind any preferences

During the project plan template discussions, the Program Manager may have desired implementation options, techniques, or tools.  When identifying any constraints such as this, explain the rationale behind these preferences and how this preference has prevented issues in the past.  This level of transparency highlights the thought process behind the decisions and helps the audience understand how decisions will be made on the project.

• Questions from the executives typically highlight areas of concern

During the presentation, questions will inevitably be asked.  These questions tend to identify the areas where the audience is concerned and provide insight into the areas to focus the presentation.  The Program Manager should spend any time necessary to address these questions.  The main presentation is of secondary importance to addressing these questions.

Have a second services individual in the room with you as well to read body language.  This person can also help steer the conversation to address additional areas of concern, provide additional business examples, or additional options to consider.

In Summary, the Program Managers can be very helpful in closing business when the prospect has implementation concerns or questions.  By introducing to the prospect the individual who will be with them throughout the process, the sales team and PM can build the necessary confidence to close the sale.

Pricing based on effort or duration

As a precursor to consulting engagements, project managers are commonly asked to price their projects.  But how does one go about pricing a consulting engagement?  A common method of pricing is to collect a set of requirements or use cases and collaborate with the individuals who will perform the work.  From this collaboration comes an estimated time per requirement or use case.  All of this is a good starting point for pricing.

 

Typically, the next step is to add up all the hours, multiply by the rate(s) of the resources and calculate a price figure.  The calculations become more complicated if there are multiple rates, time for testing, project management, and perhaps start up time are added, but one key point, I believe, is missing with this approach.

 

As project managers, we have all developed a project plan complete with our work breakdown structure (WBS), resources, and dependencies.  It is these dependencies and the resulting float or slack that drives the fundamental question for this post.  The above approach to pricing implicitly assumes that each resource is utilized 100%, a logical assumption and goal.  But we all know that each project has some float/slack in it so all resources spend some time outside of the effort defined in the estimates and are, therefore, not utilized 100%.  This additional time consumes budget and rightfully so.  The concept of the PERT chart was developed to both highlight and calculate this float. 

 

This is not to say that resources are at times unproductive but they work on items that are not explicitly defined as their task during the times of float/slack.  For more senior resources, this can be assisting less experienced resources.  Cases can be made to begin a dependent task before the predecessor is complete.  Even in those circumstances where all tasks with float are started as their early start dates, these periods of float/slack continue to exist which moves us away from the 100% utilization implicit assumption.  This leads me to the conclusion that consultants should base pricing on duration and not effort.

 

So what do about this since the amount of float on any project is different?  We left off above with detailed estimates of either requirements or use cases that were defined by the individual doing the work that remains a good starting point.  From this starting point, defining the project schedule is the next step as it will have all the WBS dependencies, define the float for this project, and the timing of when resources are staffed and rolled off the project.  From here, I develop a project budget by laying down the staffing plan that defines on a week by week basis what resources are required on a project using the project schedule as basis for which resources are needed at any particular point.  Typically, I use a spreadsheet application to calculate on a weekly basis the cost of each resource, then sum the weekly amounts for a project budget and therefore price.

 

The above approach assumes consultants are 100% dedicated to a project that is almost but not always true.  In instances where multiple projects are utilizing the same staff, moving resources between projects will minimize the differences between pricing based on effort and duration.  In most consulting engagements, this proves difficult so the duration based approach has worked well for me.

 

Requirements: Are they a necessary part of a software project?

Historically, we have taken the approach of developing requirements through many different mechanisms.  We may ask the customer for an initial set.  We may conduct Joint Application Design (JAD) sessions where we conduct meetings for multiple days to extract requirements from our customers.  These techniques and many others remain a central part of many software development and implementation projects today.  Are these techniques still central to the process?

In the late 80's and early 90's, we began to see an interesting dynamic occuring.  When asking our customers for their requirements, a couple of results were commonly seen:

• The customers knew how their current system worked but had difficulty articulating what the requirements were and in particular identifying all the requirements.  Articulating all the system features was not something they thought about or did everyday so asking them was/is a very difficult task.
• The customers also tended to describe their current system and what it did as opposed to what the business needed the system to do.  Customers know their current system so a natural place to start was articulating how they used their current system, a logical conclusion but one that tended to design the solution including potentially unnecessary customizations in commercial software.

The common end result of these sessions was a set of features that did not meet what the customer needed and in many cases were just a subset of what the system needed to do.  Lay on top the duration of the activity and length of time to develop resulted in requirements changes and utlimately a dissatisfied customer as the solution did not meet the business needs at the time of production deployment.  The end result was projects going overtime and budget due to scope creep from the project team's perspective but necessary features from the business perspective.  Both positions were fair and justified.

As these dynamics became apparent, we began to develop several tenants that remain true today.

• Customers have a greater capability to describe what is needed when looking at a prototype of the solution or at least business processes.  Business Processing Re-engineering (BPR) has been around a long time and is not as prevalent as it used to be.
• Customers have a greater capability describing what they do on a daily basis and even infrequently.
• Working or partially working software is a better tool for understanding what a solution needs to do than any form of documentation.

This has lead us down a path where use cases and/or user stories have become a legitimate mechanism for defining what a system must do.  The prototyping techniques and now the agile methodologies all expouse this mechanism as a favored way to define the scope of a project.  Combine this with business processing modeling and the project manager has a different tool to define the "What" of the system.  Process modeling and use cases also provide four additional benefits:

• Is more systematic as the team's tend to look at all paths and not just the happy path.  In a process model, a decision point must have a Yes and No path to the question.  In many questions, one or the other is an edge case so can be overlooked when reviewing just use cases. Modeling has an inherent auditing capability that tends to drive more thoroughness.
• Provides a mechanism to look for process improvements.  In many cases and once the process is defined, customers can more easily identify steps or decision points that are no longer needed or can be streamlined.
• Is agnostic of the legacy application which enables the project team to define a design or configuration for commercial software unburdened by the legacy system.  For commercial software, this is particularly useful in working within a core product and avoiding costly customizations.
• Provides a better mechanism for the test teams to become involved earlier in the project.  When developing requirements, many test teams opt to review the session output and do not contribute to the requirements development.  By using modeling and use cases when the use cases drive the structure and scope of the testing, the testing teams are motivated to participate early.  The test team also provide a valuable service as they tend to be very systematic in thinking through edge cases and error scenarios resulting in a more complete set of use cases or process flows.

In summary, defining "what" the system needs to do remains a critical part of a project.  As we have evolved, how we define "what" has more options that now include business process modeling, use case or user story definitions, and prototypes as a substitute for requirements gathering.  When beginning a project, considering the appropriate mechanism for defining scope is an early and critical project management decision.

These mechanisms have different advantages depending on whether the project is a consulting project with a scope based statement of work whether it be a custom development or commercial software implementation or a product development organization developing and improving a commercial product for sale.    These pros and cons of these techniques with respect to the project type are a topic for a future post.

Are Project Managers Farmers?

In today's competitive consulting market, Program and Project Managers have direct access to the business leaders of their customers.  In particular, my access is typically to at least the Program Management Office (PMO) and in most instances, the executive suite of the customer.  As an Enterprise Program Manager, I am uniquely positioned within a customer to discuss the overall business strategy and how technology products can assist the customer in moving their business forward or solve unique technical challenges.

Given this positioning and by gaining a customer's confidence by completing projects within the constraints agreed to in the contracts, the Program Manager can continue a program indefinitely by farming the customer.  This is a mutually beneficial situation as the customer gets a team with which they are already familiar and comfortable with as well as a team with a proven history of sucessful delivery; and the consulting company gains additional work  from the customer.

The question then becomes does this additional work distract the Program or Project Manager from the tasks at hand.  This is an individual question for each PM and relates directly to the culture within the consulting company and the overall skills of the PM. 

• Does the consulting company sales team feel comfortable with selling by a delivery organization? 
• Is the PM converservant in the customer's business and available technology? 
• Does the PM have higher level and future discussions with the appropriate people within the customer to be able to identify future business?
• Does the PM have sufficient negotiation and contracting skills to close new business?
• Does the PM and team have sufficient estimation skills to effectively scope new work?

All of these questions are unique to the individual and the companies in which they work.  For the Project Managers who are aspiring to become Program Managers, the sales and business skills needed to close business and the self confidence to close new business are paramount.