Answers for TMA1 of Contemporary issues in Project Management

1. A. Discussing the nature of traditional, agile, extreme and emertxe project landscapes.
 Traditional Project landscape: -

Traditional Project Management(TPM) is the historical root of modern project management.

Some would call it the “Happy Path.” These are the well-defined projects that populate the
project landscape and provide a good starting point for our journey.

It is well-defined projects that populate the project landscape and provide a good starting point
for project managers. The traditional project management has five basic phases, scope a TPM
project, plan a TPM project, launch a TPM project, Monitor and control a TPM project and
Close a TPM project,
Scope a TPM project: - The effective scoping of a project is as much an art as it is a science. A
number of tools, templates, and processes can be used during the scoping effort; that is the
science of scoping. Knowing our client, our organization’s environment, and the market situation
and how to adapt the tools, templates, and processes to them is part of the art of scoping.
Plan a TPM project: - The plan suggests alternative approaches, schedules, and resource
requirements from which we can select the best alternative. A complete plan will clearly state the
tasks that need to be done, why they are necessary, who will do what, when the project will be
completed, what resources will be needed, and what criteria must be met in order for the project
to be declared complete and successful.
Launch a TPM project: -
Project plans and their execution are only as successful as the manager and team who implement
them. Building effective teams is as much an art as it is a science. When recruiting and building
an effective team, we must consider not only the technical skills of each person but also the
critical roles and chemistry that must exist between and among the project manager and the team
members.
Monitor and control a TPM project: -
The controls we will learn are designed to discover out-of-balance situations early and put get
well Plans in place quickly. We can use a variety of reports as control tools. Most can be used in
numeric and tabular form but practitioners suggest using graphics wherever possible. A well
done graphic is intuitive.
Close a TPM project
Closing the project is routine once we have the client’s approval of the deliverables. It involves
the following six steps: Getting client acceptance of deliverables, ensuring that all deliverables
are installed, ensuring that the documentation is in place, getting client sign-off on the final
report, Conducting the post-implementation audit and Celebrating the success.
 Agile project landscapes: - APM is a collection of PMLC models that can be used to
manage projects whose goals are clearly specified but whose solutions are not known at the
outset of the project. These are what we call “complex projects.”
APM is the new kid on the block. Its history stretches back a little more than 25 years. As
recently as 2001, Agile software development was first codified through the ‘‘Agile Manifesto’’
put forth by Martin Fowler and Jim Highsmith.
THE AGILE MANIFESTO
‘‘We are uncovering better ways of developing [products] by doing it and helping others do it.
Through this work we have come to value: Individuals and interactions over processes and tools
Working [products] over comprehensive documentation, Customer collaboration over contract
negotiations, responding to change over following a plan, that is, while there is value in the items
on the right, we value the items on the left more.’’
 Extreme project landscapes: - Extreme projects are at the furthest corner of the landscape
where uncertainty and complexity are at their highest levels. Because of that, the failure rates
of Extreme projects are the highest among all types of projects.
The reason for the high comparative failure rate follows from the nature of the Extreme project.
These projects are searching for goals and solutions where none have been found before. Goals
are often nothing more than an expression of a desired end state with no certainty they can ever
be attained. Solutions are often totally unexplored. One of the major challenges in xPM projects
is to terminate the chosen direction at the earliest point where future failure is almost a certainty.
that allows for saving resources for a redirection of efforts.
 Emertxe project landscapes: -Emertxe (pronounced ee-MURT-see) is Extreme spelled
backwards. And indeed an Emertxe project is an Extreme project, but done backwards.
Rather than looking for a solution, we are looking for a goal.

B. Relating the project life cycle models to each of the landscapes

There are commonly five types of project management model (PMLC) types: Linear,
Incremental, Iterative, Adaptive, and Extreme PMLC Models.
For Traditional Project Management (TPM) projects, change is the exception. It is costly already
planned and committed schedules. For Agile Project Management (APM) projects, change is the
norm. It is needed to discover missing pieces of the solution. This difference is significant and
results in completely different approaches to managing such projects. While the TPM project
will use some form of Linear or Incremental PMLC model.
Each of the five different PMLC models are constructed to meet the specific needs of a project
type to which it is aligned. To that end the following five models are defined across the four
quadrants:
 Quadrant 1: TPM—Linear and Incremental Models
 Quadrant 2: APM—Iterative and Adaptive Models
 Quadrant 3: xPM—Extreme Model
 Quadrant 4: MPx—Emertxe Model
As shown in the figure below certainty is measured with respect to requirements and a solution.
The less certain we are that we have clearly defined requirements and a solution to match, the
more we should choose an approach at the high uncertainty end of the continuum. Once we
understand the nature of the project to be undertaken, we can confidently choose the model that
offers the best chance of a successful completion.

Figure 1: PMLC approaches

Figure 1 shows how the five PMLC models are distributed across the four quadrants of projects.
Note that there is some overlap. It would seem that as the project solution and its requirements
becomes less clear, the best fit PMLC could be chosen from among Linear, Incremental,
Iterative, Adaptive, or Extreme. That, in fact, is the case. The decision as to which of these five
PMLCs is best for the project is based on factors that include solution clarity. For projects that
are near the boundaries of TPM and APM, we will always have a judgment call to make as to
which PMLC model is the best fit model.
The result of the characteristics, strengths, weaknesses, and considerations of when to use
specific PMLC models is a relatively complete foundation for classifying a project into one of
the four quadrants of the project landscape and then choosing the best-fit PMLC for a given
project. This is a rich collection for effective project management.
For shown in the figure below First let’s note the similarities. We know that the purposes and
interpretations at each phase are quite different. These occur as part of the feedback loops and
the decision processes that follow the closure of an increment, iteration, cycle, or phase.
Understanding the similarities and differences gives the project manager a leg up on the effective
management of complex projects.

Figure: 2 The five PMLC models related to the traditional, Agile, Extreme and Emertxe project landscapes

 Linear PMLC Model

The Linear PMLC model is the simplest and most intuitive of the five major model types that
populate the project management landscape. This model assumes nearly perfect information
 about the project goal and solution as can reasonably be expected. The first thing to note
about this model is that each phase must be complete before the next phase can begin.
Incremental PMLC Model
The Incremental PMLC model is the second type of TPM approach and was originally posed as a
way to get products and services to market sooner but with what has been labeled “crippled
solutions”—that is, solutions that are not fully functional. It is designed to enable our client to
gain a foothold in a new market or enhance their leverage in an existing market.
 Iterative PMLC Model
Iterative PMLC models are learning and discovery models. That is a significant departure from
Linear PMLC models and is a great strength of Iterative PMLC models. So whenever there is
any doubt about the clarity or completeness of the solution and its requirements the safe ground
is to move to an Iterative PMLC model.
With each iteration, more and more of the depth of the solution is revealed and implemented.
 Adaptive PMLC Model
Adaptive refers to maintaining constant vigil on the total environment in which the project is
conducted and managed. Any change in that environment triggers an impact study to decide on
the best way to continue the project. That includes the choice of best-fit PMLC model. At present
there is only one PMLC model with these characteristics designed into the model—Adaptive
Project Framework (APF). Adaptive PMLC models are most appropriate for situations where
sizable parts of the solution have not yet been identified.
 Extreme PMLC Model
While Agile PMLC models apply to projects whose solutions are not completely known,
Extreme PMLC models apply to projects whose goals and solutions are not completely known.
Oftentimes the goal of an Extreme project is nothing more than a desired end state. It might be
achievable, but it may not be achievable as currently stated. Since there is no known solution at
the outset, the achievability of the goal is not known. In an Agile project the solution converges
through learning and discovery during iterations. In an Extreme project both the goal and the
solution converge to a final goal and solution. That may or may not achieve the desired end state
or expected business value. Obviously an Extreme project is much higher risk than an Agile
project.
2. A. The concept of project portfolio management.
A project portfolio is a collection of projects that share some common link to one another. The
operative phrase here is “share some common link to one another.” At the enterprise level, the
link might be nothing more than the fact that all the projects belong to the same company.
Although that may be true, it is not too likely the kind of link we are looking for. Some more
Effective and specific links might be the following
 The projects may all originate in the same business unit or functional area (such as IT)
 The projects may all be new product development projects.
 The projects may all be funded out of the same budget or from the same resource pool.
Whichever way we choose to define the link; one thing is almost certain: whatever resources
we have available for a given portfolio will not be enough to meet all project requests for that
portfolio. Some choices have to be made, and that is where Project Portfolio Management
takes over.
Project Portfolio Management includes establishing the investment strategy of the portfolio,
determining what types of projects can be incorporated in the portfolio, evaluating and
prioritizing proposed projects, constructing a balanced portfolio that will achieve the investment
objectives, monitoring the performance of the portfolio, and periodically adjusting the contents
of the portfolio in order to achieve the desired results.

B. Common manifestations of projects that are distressed.

The following characteristics are symptomatic of a distressed project:

The project has exhibited a performance trend that, if continued, will result in its failure.
Whenever the cumulative history of one or both of those metrics exhibits certain trends, it
suggests that the project is out of control, and the reason for the trends needs to be identified and
a decision needs to be made as to how to proceed. A growing schedule slippage is one such trend
that, if continued, will lead to failure.

The project’s performance has exceeded one or more metric values and is a high risk for
failure:
When any one of these metrics exceeds its trigger value, the project is at high risk for
failure. That sets off a series of activities designed to identify the source of the anomaly and the
corrective action that needs to be taken. A significant schedule slippage due to a bad estimate, a
mistake, and serious vendor delays are three such events that may result in project failure.

The project has recently experienced some significant change that may result in failure:
Oftentimes these changes are related to personnel or other major organizational shifts. Even
though the project performance metrics do not indicate any problem, the environmental change
may be sufficient to throw the project off course. A change of sponsor and a loss of critical
resources are two such changes that may result in a distressed condition and eventual project
failure.
If any of the preceding situations happen, it should immediately trigger a project intervention
process designed to discover the reasons for the distressed condition, fix the condition, and re
plan the project going forward.
Almost similar symptoms have been depicted by Mc. Donagh & Partners (2018). These include:

 Performance trends- has the project been exhibiting poor performance trends and do
they look set to continue this way if things don ‘t drastically changes right now? If a
project is out of control an immediate assessment need to take place to find the case of
the problem.
 Slipping Schedule. -If the schedule of our project keeps slipping further and further
down the calendar it’s probably because initial estimate and time frames were grossly
incorrect. Other factors like bad estimates, project mistakes, and vendor delays can also
contribute to schedule problems.
 Organizational Change: Change in personnel, restructuring, environmental changes,
and loss of critical resources are all factors that can bring about project chaos and cause a
project fall flat.

Factors Causing Projects become Distressed

Poor, Inadequate, or No Requirements Documentation
Once requirements have been generated ask our self what our level of confidence is that we
have done the best job possible. we should be reasonably certain that we have identified the
necessary and sufficient set of requirements and only their detailed decomposition is suspect.
we can employ a number of Agile Project Management (APM) project management life cycle
(PMLC) models if requirements documentation is less than satisfactory or if we expect a high
rate of change.
Inappropriate or Insufficient Sponsorship
Some sponsors take their job of sponsorship seriously. Others do not. As project manager, we
should keep the project very visible to our sponsor. Sending an e-mail once a week is not
sufficient. we should try for face-to-face meetings if there is any doubt about our sponsor’s
attentiveness to the project.

Complexity of Requirements Not Recognized

Don’t assume that the project is simple. That thinking leads to a sloppy job of requirements
gathering and documentation. we are heading for trouble if you can’t get requirements done
correctly, realize what we have or don’t have, and then choose the best-fit PMLC model.
our risk management plan must anticipate the unusual and have the appropriate mitigation
plans in place. As requirements become more complex or less complete and clearly documented,
the risk of the project becoming distressed goes up.

Unwillingness to Make Tough Decisions

How easy it is to get a project approved, and how hard it is to pull the plug on the most distressed
of projects. If we want to get the sponsor’s attention, recommend terminating their hopelessly
distressed project. But need to be careful that we don’t hurt our own reputation in the process.
We needn’t be defensive just honest.
Some projects have a very powerful sponsor. They may defend the project beyond reason, but
few are willing push back or take them on. The president of our company will often be the
major culprit here. If we are going to take him or her on, we had better do our homework.
Lag Time Between Project Approval and Kick-Off
Getting a project approved is one thing. Getting it started is another. If the time between approval
and startup is too long and the completion date is firm, project risk goes up. Any date-dependent
tasks are compromised by the delay, so avoid using those in our project schedule if possible.
we are also at some risk of losing team members due to the delay, especially those who have
scarce skills that we need but so do others.

No Plan Revision after Significant Cuts in Resources or Time

Budget cuts, staff cuts, and shorter deadlines are not unusual. Under those circumstances, many
project plans are not changed. Despite our pleas, senior management says something like this:
“You’ll figure out how to do it anyway. You always have.” Most project managers are helpless
to do anything here except keep quiet. Many do not have the tools to push back with an
intelligent business argument.

Estimates Done with Little Planning or Thought

Far too many project managers don’t take estimation seriously. They throw some numbers at the
plan, and if no one objects, the numbers stay. The correct strategy is to get estimates from staff
members who have done the tasks before or will be assigned to do the task on this project.
Unless they have been a credible source in the past, we will want some validation of the
estimates they provide. Getting a second opinion from someone who is not on the project can be
a good validation strategy.

Over commitment of Staff Resources

This continues to be a major problem. Projects are often approved without assessing staff
availability. You may have the skills needed, but the people with those skills are already
committed to other projects and cannot work our project into their schedules. Dealing with this
situation effectively requires a Human Resources Management System (HRMS) with skills
inventories and staff scheduling capability.