GTD for PMs - Part III

One of the roadblocks to progress we frequently encounter as Project Managers is decision making. Sometimes we might benefit from a strategic framework -- what decision will best align with our mission and vision? But more often than not, we are hurried to make decisions in a world of instant communications and rapid change. How can we avoid analysis paralysis or making the wrong decisions?

Enter Suzy Welch, wife of former GE CEO Jack Welch. Suzy has just introduced what is being hailed as a life changing concept -- 10 minutes, 10 months, 10 years:

All it takes to begin are three simple questions: When faced with a complex dilemma, stop and ask, "What will the consequences of my options be in 10 minutes, 10 months, and 10 years?"

An extremely simple concept, a small modification can make it applicable to financial decisions. Think of the value of the money if not spent in 10-10-10 and weigh against the value of the expenditure in 10-10-10.

For more information about decision making with 10-10-10, visit Suzy's new book site at http://www.suzywelch101010.com/index.htm.

Contractor/Vendor Selection: Bridging The Communication Gap

Susan Peterson, M.B.A., PMP 2008,
Copyright Susan Peterson, All Rights Reserved

In the continuing series on outsourcing project work this month’s column addresses the challenges related to selecting those individuals and/or organizations that will provide the expertise needed for specific activities. All too often this process is filled with “communication disconnects” in documenting what is needed from contractors/vendors. Whether one uses requests for proposal (RFPs), requests for information (RFIs), or other types of vendor solicitation documents, clear definition is critical. I have participated in the election process in multiple roles including leading the selection process, writing solicitation documents for clients, and responding to client proposals. The following areas are primary considerations to effectively facilitate the project vendor selection and subsequently the contracting process.

Be specific -- even if it hurts.
There is no substitute for clarity in specifying what activities need to be performed. Too often project leaders feel that there is not enough time to fully document requirements or specifications. They also may feel that providing detailed documentation means that there will be no room for negotiation if there are changes during the project. Sometimes, there are situations when many of the details regarding a project work need are unknown. In any case, providing more clear definition is better than merely documenting the are minimum requirements. In those instances where little is known, the solicitation document can state the situation and request that the respondents provide their best solutions. Otherwise, the vendors will be forced to respond vaguely or to guess (often incorrectly) about what was intended.

The project manager should also include a template for responses in order to obtain usable information that is comparable across all responses. For example, a cost template should be provided so that the breakout of costs can be readily compared among vendors. Vendors have a variety of costs that may or may not be included in an hourly rate, so the project manager needs to know what is covered in order to avoid surprises later. Also, it may appear to speed the review of responses by including a number of expertise or capability questions that can be answered "yes" or "no". However few respondents will answer "no", knowing full well that a ”no” response can be the basis for rejection while there is “always a way” to provide the “yes”.

“How ‘good’ is ‘good’”?
In order to avoid nasty confrontations during the course of the project that are always counter-productive, the solicitation should include tangible definitions of quality and performance. These definitions should correlate not only with the final deliverables but also with appropriately scheduled interim deliverables. If the potential respondents have not performed project work for the organization in the recent past, these interim deliverables may be scheduled more frequently. Acceptance criteria should also be clearly defined. For example, there are numerous “horror stories" about the disasters caused by the interpretation of "The
software has been fully tested”.

It never gets any better than the “courtship”
One would assume that potential contractors/vendors would present their best possible images to project managers during the selection process. However, I have seen solicitation responses that consisted of photocopied pages stapled together in no apparent sequence. Conversely, I have also seen responses that ere nothing but “color-coordinated glitz". While few relationships are perfect, the project manager needs to assess the overall caliber of a contractor/vendor's response in order to better predict the quality of the future relationship.

Contractors/vendors are human beings.
I once heard about a company that circulated many solicitations but that never awarded any contracts. This company took all of the responses and used the information to conduct the work in-house. It is expensive for contractors and vendors to respond to project solicitations. These costs are not recoverable. Project managers need to be prudent in soliciting responses to proposals. Once the contract has been finalized, all respondents should be notified. While a contractor/vendor may not be suitable for one project, it may be a “good fit” for other projects.

As with all successful relationships, effectively working with outside project personnel requires good upfront research, objective review, and ongoing management. Next month’s column concludes the outsourcing series with best practices to manage contractors/vendors in a project environment.

Susan Peterson, M.B.A., PMP, is a consultant who manages diverse programs and projects in both the private and public sectors for individual organizations and consortia. She also conducts enterprise assessments of project portfolio management practices. An overview of her program and project specialties is available at http://www.pmi-sd.org/Consultants. She teaches the Project Management Simulation capstone course in the University of California, San Diego, Project Management Certificate program and is a member of the curriculum committee. She can be contacted at susanada@aol.com.

A Happy and Safe Fourth of July

Enjoy the holiday ... back next week!

The Relationship of Project and Product Management

I've started exploring the relationship of project and product management, particularly as they may relate to smaller companies. Each seems to have their separate body of literature, but there are some close ties.

Let’s start by looking at the PMBOK® Guide, Fourth edition definition of project. Note that “product” appears as part of that definition. This leads us to believe that to create a product, we should have a formal project:

“A project is a temporary endeavor to create a unique product, service, or result...Temporary does not necessarily mean short in duration. Temporary does not generally apply to the product, service, or result created by the project; most projects are undertaken to create a lasting outcome.”

Project managers know that projects have life cycles. Products have life cycles as well. The product life cycle usually starts with an organization such as Sales and Marketing or Engineering developing a product idea. This may be internally generated or driven by customers or consumers. The idea may be for a brand new product (e.g. the introduction of an iPhone) or for an improvement to an existing product (e.g. successive versions of the MS Windows OS since the introduction of Windows in the 90s). The final stage of the product life cycle is retirement – the product is no longer produced or supported by the product creators.

Projects may be necessary for one or more phases of the product life cycle. These may include R&D projects to determine project feasibility, projects to create a new manufacturing facility, or the actual product creation.

For small companies or simple products, the product and the project life cycle may coincide -- a single project. In this case, the product/project manager needs to bring together Sales & Marketing, Sr. Executives, and the Business Owners of the organization to develop the project charter. They must carry out several essential product management functions to define and create the product, such as:

• Product ideation
  
• Competitive analysis
  
• Business case development
  
• Generating the sales and marketing plan, including product introduction
  
• Managing the infrastructure needs to support the product (e.g. order taking, order fulfillment, inventory control) which may generate internal projects
  
• Make investment determinations
  

The project charter sets forth the high level product/project goals, budget, schedule, and resources and represents the initial product scope. These project charters will compete with other projects in the organization, possibly including those which support the product. The executive team will need to take a broad view of the product and project portfolio to properly sequence the work.

The small product/project has risk and cost management implications for the project manager. When products and projects coincide, the product/project manager needs to take a broader view than the immediate project. The profit and loss statement for the product needs to look at all the costs, including those outside the immediate product creation. These costs may include advertising and infrastructure costs. For project managers, cash flow usually isn’t a consideration, however in these circumstances, cash flow review is critical. A late product often has more far reaching implications and broader risks than a late project, and may include:

• Loss of competitive advantage or position
  
• Loss of market share
  
• Loss of revenue contributing to cash flow
  
• Wasted resources
  

These risks may be external and related to what competitors are doing.

A prime example is the case of the Burroughs Scientific Processor, originally expected to compete with Cray Systems for the very limited supercomputer market. The limited applications, high R&D costs, and resulting high prices created a limited niche market. Burroughs and Cray both expected to sell no more than about 50such systems initially. When unmitigated, high impact risks caused set backs for Burroughs, more than 50% of the estimated market was captured by Cray. Faced with the prospect of limited or no sales, Burroughs abandoned the BSP product concept and mitigated the losses through the creation of an “attached processor” which boosted the capacity of their existing mainframes.

In conclusion:

• Products require projects.
  
• There may be overlapping or interweaving cycles for projects and projects.
  
• For small companies and simple products, the project and product cycles may be nearly equivalent.
  
• In the case of equivalent life cycles, the responsibilities of the product/project manager are broader and include examining profit and loss, cash flows, and broader risk management.
  
• Failed projects in this environment often carry more risks that have broader implications for the organization.
  

For more information about product marketing, visit Pragmatic Marketing. If you have any thoughts on this, please leave a comment or drop me a line at sdcapmp@aol.com.