Managing Technical Project Teams Case Study 1PMBOK® GUIDE AREAINTEGRATION MANAGEMENT and SCOPE MANAGEMENTSUBJECT AREA: DEFINING A PROJECTBackground Assignment 1: Case Study 1
PMBOK® GUIDE AREA
INTEGRATION MANAGEMENT and SCOPE MANAGEMENT
SUBJECT AREA: DEFINING A PROJECT
MedTech Products was undergoing favorable growing pains. Business was good. New product
development was viewed as the driving force for the company’s future growth. The company was
now spending significantly more money for new product development, yet the number of new
products reaching the market place was significantly less than in prior years. Also, some of the
products reaching the market place were taking longer than expected to recover their R&D costs,
while others became obsolete too quickly.
Management recognized that some sort of structured decision‐making process had to be put in
place whereby management could either cancel a project early before massive resources were
committed or redirect efforts to different objectives. David Mathews was assigned as the project
manager in charge of developing a new product development (project management)
methodology for MedTech Products.
David understood the benefits of a project management methodology, especially as a structured
decision‐making process. It would serve as a template or a repetitive process such that project
success could be incurred over and over again. The methodology would contain sections for
project scope definition, planning, scheduling, and monitoring and control. There would also be
a section on the role of the project manager, line managers, and executive sponsors.
To make the project management methodology easy to use and adaptable to all projects, the
methodology would be constructed using forms, guidelines, templates, and checklists rather than
the more rigid policies and procedures. This would certainly lower the cost of using the
methodology and make it easier to adapt to a multitude of projects. The project managers could
then decide whether to implement the methodology on an informal basis or on a more formal
The first draft of the new methodology was completed and ready for review by the vice president
(VP) of operations who had been assigned as the project sponsor. After a review of the
methodology, a meeting was held between the sponsor and the project manager (PM).
“I have read over the methodology. Is it your expectation that the methodology should be used on
“We could probably justify using the methodology on every project. This would give us a really
good structured decision‐making process.”
“Using the methodology is costly and perhaps not all projects should require the use of the
methodology. I can rationalize the use of the methodology on a $500,000 project. But what if the
project is only $25,000 or $50,000? What if the project is 30 days in length rather than our usual
6 to 12‐month effort?”
“I guess we need to define the threshold limits on when project management should be used.”
“I have a concern that we should define not only when to use project management but also what a
project is. If an activity remains entirely in one functional area, is it still a project according to
your definition? Should we also define a threshold limit on how many functional departments
must be involved before we define an activity as a project?”
“I’ll go back to the drawing board and get back to you in a week or so.”
1. What is a reasonable definition of a project?
2. Is every activity a project or should there be a minimum number of functional boundaries
that need to be crossed? If so, how many boundaries?
3. How do we determine when project management should be used and when an activity
can be handled effectively by one functional group without the use of project
4. Do all projects need project management?
5. Since the use of a formal project management methodology requires time and money,
what should be “reasonable” threshold limits for its use?
Purchase answer to see full