BOTCHED - Project Post-Gazetteprojectgazette.com/archives/PG_Nov2013.pdf · MuTo Perf 12 Mstr Scheduler 19 urrent Events 27 Risk 29 PPPM 30 ompliance 31 PM Squared 30 ITIL Review

P R O J E C T P O S T - G A Z E T T E V O L U M E 2 0 1 3 , I S S U E 1 1 N O V E M B E R 2 0 1 3

Copyright © MCLMG LLC 2013

What’s HOT in this ISSUE Silent Influencing 11 Top 3 Fears of PMs! 13 Fixing the Wrong Problem 15 Rescuing an IT Project! 18

Columns The Risk Line 7 The Schedule Dispatch 8 PPPM Roadmap 9 The BA Forum 10 Practically Proven 11 The Consultant in Jeans 13 In My Opinion 14 Testing the Waters 15 Well-Skilled PM 16 Compliance Central 17

BOTCHED! Is Failure the New Normal for IT Projects???

Are the recent, very public failures of govern-ment technology and communications projects on almost all continents going to become the norm for such endeavors? Why can the private sector succeed on IT outcomes and the public

sector have such a difficult time delivering the business value to their stakeholders and the general public? Our entire issue this month is all about how the public sector succeeds and fails in their IT project management activities.

The Project Whisperer 18 Line in the Sand 20 The Project Eye 21

Targeted MuTo Perf 12 Mstr Scheduler 19 Current Events 27 Risk 29 PPPM 30 Compliance 31 PM Squared 30 ITIL Review 33 Risk Analysis 34 Project Success 35 Techniques 36 Risk Basics 37 Risk Concepts 38 Games 24

November 2013 Issue Special

Discover the issues or concerns when planning & managing IT projects.

Have you figured out the new Normal for both our economy and your pro-

jects? Read what SA Mitchell has to tell you.

The New Normal! 22

Is Agile compatible with government IT projects? Find out from IT industry guru Alistair Maughan on the issues that can arise. Agile&Gov IT Projects 23

How do you build a house from the top

down? Read our 11 page case study supplement!

CS Supplement - Muto 74

™


P A G E 2 V O L U M E 2 0 1 3 , I S S U E 1 1

November 2013 Issue Contents

Front Page Editorial 4th Page Mini

Targeted Articles & Extras

Columns

The Risk Line—”Risk in the IT Environment”

PPPM Roadmap—”PM Discipline”

The BA Forum—”Assigning the BA First!”

Practically Proven—”Silent Influencing”

Consultant in Jeans—”Top 3 Fears of an IT PM”

Schedule Dispatch—”Schedule Baseline”

Testing the Waters—”Fixing the Wrong Problem”

Compliance Central—”IT Compliance”

Project Whisperer—”Rescuing an IT Project, P1”

Well-Skilled PM—”Critical Chain vs. Traditional”

Line in the Sand—”Is Poor PM Ethical?”

MuTo Performance Corp—Resources Are Inadequate

Current Events I—”The IRS Tax Exempt Scandal”

Risk Mini—”Goal Risk Assessment & RBIA”

Current Events II—”The ACA Web Site”

PPPM Mini—”Strategic vs. Tactical Projects”

Compliance Mini—”IT Compliance Organizations”

Understanding Cognitive Biases in DM, P1

In My Opinion

What is AXELOS’ ITILv3(r)?

Progress Checking an IT Project

Comments & Contact Information

7

8

9

26

12

74 73

24

12

13 20

18

17

16

15

11

33

31

28

27

34

32

30

29

Table of Contents Next Page Previous Page

Lead Article

10

19 The Master Scheduler—”Agile vs. Waterfall”

The Project Eye—High Failure Rate of IT Projects 21

What is a ‘Shared Mental Map?’ 35

Games & Things to Ease the Mind

Using Linear Regression to Improve Decisions II 36 Risk Basic & Intermediate Concepts 37

CONSULTANT’S CORNER TRAINING TERRACE 71 70

SPECIAL — Case Study Supplement on Resources


sulted in a savings of $1000 on my property taxes illustrated that state governments can and do provide solid business value from their web presences. So what is the problem with federal or sov-ereign level IT projects that make them so prominently candidates for failure? The US or UK Govern-ments’ recent failures are not the only examples of so many.

[Google these IT project failures for these exam-ples.]

We have to final-ly realize that the self-proclaimed project manage-ment standards bodies, govern-ment methodol-ogies purveyors, and even the newfangled “speed-‘em-up” delivery models are failing our industry. The application of standard pro-cesses, customer-involved daily huddle sessions, loosey-goosey ‘no-requirements-needed-change-as-you-want’ methods are not

working!

So is there a solution? YES!

As we have pointed out before in many of our articles that the solu-tion is very simple and straightforward – FOCUS ON THE DELIVERABLES!

Do not focus on processes, proce-dures, methods, or the latest de-livery solution. There is one thing that EVERY project customer and

(Continued on page 5)

With the current debacles in US Government IT and Web projects making news around the world, the pop dictionaries are becom-ing filled with terms that used to be reserved for geeks and tech-nocrats. Words such as graphical user interface, user acceptance testing, web front end, functional requirements, go-live date, pro-ject schedule, resource calendars, and more. Thus, through the very public failure of the US Govern-ment’s widely touted healthcare web site, the failure of IT projects once again takes center stage – this time in the living rooms and break room discus-sions.

We have heard and watched the testimo-nies from those involved in the design and develop-ment of the healthcare site point fingers at each other like kids caught writing on the walls trying to blame their siblings. It is quite humorous to watch, but painful to think about the conse-quences. IT projects have now become the poster children of the failure of the current project management discipline. If this does not hasten the needed changes to our profession then it will only speed up its demise. Project managers the world over are now taking it on the chin and we must do something before

our professional becomes the “butt of late night” talk show skits, monologues and well-meaning country singers.

Before this very public “crash and burn” of a US Government IT pro-ject, most people did not even know of project management contractors, requirements, deliv-erables, or testing. Now these project management activities

are coming to the attention of every daily news consumer. A compounded issue of this particu-lar IT project is that most people who use the Internet have taken for granted the success of “retail” websites such as Google, Yahoo, Amazon, 1800 Flowers, or Price-line. Even my recent experience with the New York State Tax web-site that worked perfectly for the function for which I visited that required less than 60 seconds to complete a transaction that re-

Is Failure the New Norm?

LEAD ARTICLE P A G E 3 V O L U M E 2 0 1 3 , I S S U E 1 1

“...the failure

of IT projects

once again

takes center

stage — this

time in the

living rooms…”

“...most people

who use the

Internet have

taken for

granted the

success of

‘retail’

websites…”


P A G E 4

team cohesiveness studies of Festinger, Lott, and Hogg, the value of team bonding and longevity is well known. However, for some reason it is categorically not practiced in the project management profession.

The PPG believes that this long-standing and ineffec-tive practice be given the airing out that any dusty, moldy, or axiomatic princi-ple in any discipline should be treated to periodically in order to determine its con-tinue value to the right and proper practice of the pro-fession. This topic will be given a more detailed de-construction in the “In My Opinion” article of this is-sue. Do not be afraid to question, inspect, or dissect even the most rigorous of our professions’ tightly held principles – this is how a practice stays fresh and rel-evant with growing applica-ble value.

“A significant body

of knowledge

exists that seeks to

make the

alternative that

keeping teams

together has more

than value…”

Permanent IT Project Teams

Editorial - Who’s Minding the Business? As a business analysis con-sultant in addition to being a project manager, I have the interesting experiences of being both a PM and BA on the same projects for my clients. While for smaller to medium projects this can work to an advantage, one has to keep the very differ-ent goals and focus of each discipline from cross con-tamination of the other. The PM side is focused on the overall project progress and communication with stake-holders, the BA side is con-stantly seeking the align-

ment of the project triumvi-rate: business problem, re-quirements, and solution.

The juxtaposition of these thought processes brings a unique perspective on one of the most significant, but often ignored by inexperi-enced PM and BA: the pro-ject business case. Not re-ferring to the project char-ter which according to cur-rent business analysis lore should contain the business case, I am referencing the actual documentation of the reason the project is of im-portance to the organiza-

tion. More and more pro-jects on which I am asked to consult I am finding that while the project charter (commercial) or Statement of Work (SOW government) is available, the stated busi-ness justification for the project is simply taken for granted and not specifically defined.

This oversight presents a very real threat to the suc-cess of the project for it causes a breakdown of the fundamental circle of pro-


idea that was just practiced in years gone by and has become part of the lore or history of project manage-ment that we consider it sacrosanct or scared? Is there value in such a defin-ing characteristic of project teams that we teach or practice it liturgically?

A significant body of knowledge exists that seeks to make the alternative that keeping teams together has more than value, but real power. Beginning with the study of the Mann Gulch wildfire disaster of Helena, Montana in 1949 where 13 trained, and experience firefighters lost their lives when team dynamics disin-tegrated to where the smoke jumping crew team could no longer make sense of their leader’s action or frantically issued orders to drop their equipment, start back fires and lay down in the ashes while the wildfire raged around them to the

As with all sound profes-sional or industry good prac-tices, the need to revisit their value and application to the practice of the disci-pline should be an activity of frequency as any other housekeeping chore that organizations assign to themselves in order to stay flexible and vibrant. Such an idea has begun to require the attention of the spring cleaning type where instead of just accepting it without thought, truly begin to ex-amine it and its value to the processes that many just blindly accept since it is listed in some body of knowledge.

The practice I am alluding to is that of treating the pro-ject teams like the delivera-bles of a project – unique, but temporary. It is the tem-porary characteristics that I am calling attention to in this initial treatment. Why are project teams consid-ered temporary? Is it an

Post-Gazette’s

Editor-in-Chief:

PH Lohnes, PMP

These are the

opinions of the

PPG Editorial

Board — Not of

any writer,

advertiser, or

subscriber.



ment internally to increase the business value of your operations and generate new opportunities then you will have to deal with the fact that this so “out in the open” project management fail-ure is going to swamp many PM, BA, and project teams. You will find yourself having to defend your position as a PM, BA or pro-ject management user as if you were on the same hot seat that the news has been replete with over the past several days. Re-member how the WorldCom, Enron, and Lehman Brothers scandals almost sank their re-spective industries, and how long they had to spend repairing their public reputations. Some have yet to succeed.

The solution is to stop using the same, tired, and outdated pro-cesses even though they have been packaged into new editions, new web sites or under new names. If what you are doing does not succeed, then try some-

thing else – anything else goes the old adage. In this case, what is not working is the current in-dustry standard processes and methods that focus on the how and not the what. The ‘how’ are the processes and procedures, the ‘what’ are the “fit-for-use” deliverables. When it comes to the sign-off of the deliverables for closing the project, I have never been asked nor have I have ever spoken with a PM that has had a customer say “oh, do not worry about the failed outcomes, ex-plain to me HOW you produced the project deliverables.”

The only goal that makes any sense to a project sponsor or cus-tomer or end user is having the project’s delivered to them ready for use within the definitions of their quality and other con-straints so they can begin to gar-ner business value from the pro-ject’s outcomes. The only time the processes, procedures, and methods of the project become of interest to the project stake-holders is when the project fails to deliver on its only true goal – the production of deliverables that meet the stakeholders’ ex-pectation.

We at the PPG are hoping that the project management night-mare playing out on every televi-sion set in the known world will finally bring the PM / BA disci-plines to the reality that they MUST change, they HAVE to change, they WILL change one way or the other. Either the disci-plines realize that they are not providing the value for which they are being compensated and need to do so immediately, or they will be replaced by another profession that can deliver on the failed promises of the current bodies of knowledge. This is a watershed moment for our pro-fession. Failure can no longer BE the norm for IT projects, nor should it be.

sponsor wants – “fit-for-use” de-liverables. They do not care one wit about the processes you use, the tools employed, the tech-niques applied, or the methods utilized. Customers and project sponsors care about only perfor-mance and the production of their defined “fit-for-use” deliver-ables. It is truly this simple and this specific.

The project management and business analysis disciplines are going to have to reinvent them-selves with all the bad press their professions are receiving over this so public a failure. The public and project sponsors are going to paint all IT projects with the same dark and smelly brush that this PR nightmare is providing them. It will not matter if you are a PMP®, CBAP®, MCTS®, or PhD. If you are an IT project manager, a compa-ny that competes for government projects, or uses project manage-

(Continued from page 3)

Lead Article (cont.)

“The project

management

and business

analysis

disciplines are

going to have

to reinvent

themselves…”

“The solution is

to stop using

the same, tired

and outdated

processes even

thought they

have been

packaged into

new editions..”


ject causality by not clarifying for all stakeholders, team members, and organization management the reason for the project’s existence. Without this statement of need, I believe the project’s central theme is obscured or even lost in the rush to begin the pro-cesses and procedures of the project’s initiating phase. Every-one loves to begin a pro-ject – the newness, the professional aura simu-lating that of a newly purchased car, the “undiscovered” country so to speak. The kick-off meeting is one I normally do not have issues in obtain-ing attendance or participation. How-ever, once begun, the luster fades, the first scratch dulls the joy of own-ership, and now it becomes another daily grind problem to deal with as the new purchase is the subject of complaints, frustration of break-downs, and demands of attention for upkeep.



stantiation artifacts for without a clar-ified understanding, description, and existence of the reason for applying the scarce resources of any business entity towards the production of “fit-for-use” deliverables, the value of a project’s outcomes are lost without direct impact to the solution of the

original dissatisfac-tion of the status quo in which the project finds it true horizon. The business value of a project is embodied in the business case as the following rela-tionships that de-scribe the closed loop characteristic of any

valuable project illustrate:

All projects begin as a dissatisfaction with the status quo of an organiza-tion’s current business environment for without such dissatisfaction the need to produce unique “fit-for-use” deliverables would simply be an exer-cise in wasteful application of re-sources without an expected return on investment or justification for ex-penditure of limited stores and inven-tory. From the dissatisfaction, the requirements of its resolution take shape as stakeholders are elicited for their needs, demands, and constraints which any acceptable solution of the dissatisfaction must possess. The re-quirements then define the subset of only feasible solutions from the pool of all possibilities from which a most acceptable solution is chosen for im-plementation. From this choice, the project seeks to produce the solution artifacts that if achieved successfully will when taken in a totality form the expected resolution to the initial dis-satisfaction of the status quo – the circle is complete and succinct.

By eliminating or by ignoring the busi-ness case the stakeholders of a pro-ject starve the component that can throughout the lifecycle of the project keep the team focused providing un-derstanding and motivation for the day to day actions of producing those


Editorial (cont.)

So if the business case is so important, why is it not more often in place or given more priority? Since the busi-ness case and its documentation oc-curs in the nebulous landscape of the “pre-project” fog where authority is not definite, stakeholder interest not

apparent or PM assignment not actu-alized, the business case lacks a cham-pion of real substance. Like figures in the early morning mist, it silently passes from one reluctant player to another until the threat of dwindling funding demands it formation or de-mise – it is rushed into existence with-out any solid structure meeting just the minimum solidness of definition.

Organizations need to exert the efforts of a maternity ward nurse in the care and nurturing of these very fragile, but so important project in-


The Risk Line: Risk in the IT Environment


It was once said that insanity is: “doing the same thing over and over again and expecting a differ-ent result.” We may laugh at this saying and half-heartedly tell our-selves that this type of insanity does not pertain to us; but as Project Managers (PM) if we continue to use the same meth-odology over and over again to manage our projects but we do not see any difference in our out-comes. Many statis-tics have shown pro-jects are still failing at a rate of 70%, but PM continue to use the same traditional methodologies to manage their projects, over and over again. Is this not insani-ty?

Let us take a look at exactly what is Project Management? A com-mon definition of project man-agement is the planning, organiz-ing, motivating and controlling assigned resources to product fit-for-use deliverables that are de-fined by the customer or project sponsor.

So what is the role of the PM in project management? The PM that has been selected for each project has the responsibility to plan, execution, and close the projects they manage. The prima-ry goal of the PM is to ensure the production of the project’s fit-for-use deliverable(s). This includes the challenge of the PM achieving this goal while managing the pro-ject constraints of time, scope, cost, quality, and risk. These con-straints are defined at the pro-ject’s initiation.

This article explores the concepts of PM managing risks on IT pro-jects under the other project con-straints. After looking at the history of why many IT projects

fail, we have found that most IT projects have the same concerns surrounding their project con-straints. Yet PM continue to man-age their IT projects the same way over and over again.

As we explore the management of risk on IT projects, it is im-portant to understand how to correctly identify project risk. Where most PM get bogged down in risk management is in the initial stage of risk identifica-tion, because PM do not limit project risk to what will impact

“The first step to

identifying risk

on your project

is to identify

your

deliverables.

Risks are tied to

your project’s

deliverables.”

Cheryl A. Wilson

PMP, PMI-RMP, CCEP

Featured Columnist

the stated business objectives – their deliverables. Project deliv-erables are defined in the State-ment of Work (SOW) or project charter. A risk is not a risk to you unless the occurrence of the risk impacts your deliverables. The question should not be, what are my risks, but the question should be, what are my deliverables and what are the threats to my deliv-erable(s)?

Step One.

The first step to identifying risk on your project is to identify your deliverable(s). Risks are tied to your project’s deliverables. To miss this step is actually missing the whole purpose of risk man-agement. Many PM list every-

thing they can think of that is a problem in their project and label these “problems” as risks. They are not risks; they are exactly what the word means, problems or concepts needing management attention. Just because something needs the attention of a trained, experienced project manager does not make it a risk.

A project deliverable is the agreed upon fit-for-use output that must be produced to complete a

project or task. MCLMG has de-veloped a concept for managing projects called: Deliverable Cen-tered Project Management (DCPM). The focus of DCPM is to focus project management on the production of the deliverables which then removes many obsta-cles in the way of most PM and simplifies the concept of project risk management. Samples of deliverables could be:

A product

A design document




The schedule baseline – the mere mention of this artifact either strikes terror in the heart of the project scheduler or brings tears of joy from the project sponsor that they finally have a “line in the sand.” In either case, the schedule baseline is taken by many to be the quintessential proxy of the project itself. Many times I have heard what may now pass for a project adage of “I have a schedule, therefore I have a project!”

The schedule is very important to a project, but it must not become its entire definition. The project management plan or its equiva-lent depending on the project / program / portfolio management (PPPM) methodol-ogies of the organi-zation should define the project’s future and planned direction. The sched-ule is to represent the time-phased relationships of the project’s de-fined work efforts as described in the project’s activity list which should find its source of origin in the project’s Work Breakdown Structure (WBS). All of these arti-facts and interrelationships have been discussed in previous issues of the PPG.

Not to take away from the im-portance of the project schedule nor those that prepare this sig-nificant artifact, but the schedule is not the most important nor the most core project document. The

schedule is the result of many processes and activities that re-sults in a time-phased database of tasks, calendars, resources, durations, and costs which pro-duces some very nicely colored bar charts called Gantts. OK, please do not get upset because of what you may perceive is a dismissive or disrespectful atti-tude towards the project sched-ule. As project managers, we have a love – hate relationship with this project component. It is both the oracle of project pro-gress and hammer of doom when things do not work according to plan.

With the project schedule under-stood, what is a schedule base-

line? This is at the heart of why project schedules are not per-forming the function for which they were initially designed – a planning document from which the project manager (PM) can execute their project manage-ment plan. The schedule with all the powerful software tools and techniques has now become the project proper – everything in many IT projects revolves around the project schedule and all the myriad number of iterations that the project scheduler performs on it almost hourly. Really! Is the

“A schedule

baseline as with

ALL project

baselines must

exhibit two very

important

characteristics:”

4. The Schedule Baseline

schedule supposed to help man-age the future or be an exact rep-resentation of project history??

A schedule baseline as will ALL project baselines must exhibit two very important characteris-tics:

1. It must be approved, and

2. It must be placed under con-trol.

Of the two, the second is proba-bly more conducive to schedule valuation than the first, but both are important and necessary to have a properly functioning pro-ject schedule. Now I will probably lose many of our schedule read-ership at this point, but this con-cept is so fundamental that we will risk such loss. A schedule is NOT to be tweaked every day to make it the project chronicle or the project historical document. A schedule to show the PM and key stakeholders what is PLANNED for execution and that if executed correct will result in the production of “fit-for-use” deliverables.

Who should approve the sched-ule? This will depend on both your organization and the size/complexity/visibility of your pro-ject. Smaller, less complex pro-jects can have their schedules approved by the PM and/or pro-ject sponsor. For more complex and larger projects, the number and extent of schedule approvers will need to increase. Remember the schedule specifies the near term tasks in additional detail than more future distance tasks thus requiring future updates to the schedule that will need to be approved for their detail not summary conditions. Project schedules can show the summary part of a project’s planned future


PPG Research Staff

The Schedule Dispatch



tion schedule more difficult to keep and if allowed to fester, may ultimately doom the initial falter-ing steps into the PPPM realm to just as those that are doing a “go slow” activity believe it will be-come – a business lava lamp (for those that do not know what this is, google it), i.e., an another ‘looks good,’ but does not do anything business idea from those that do not do the actual work. The organization’s senior leadership team (SLT) must en-sure that they are going to sup-port the PPPM endeavor with something that they may not use to wielding – managerial disci-pline.

At this conjunction, an example may be of value. During a recent portfolio engagement, I was asked to design, plan, and devel-op a new PPPM (actually they only called it a PPM solution – leaving off the program vector) solution component based on an existing complex, expensive PPM tool that the organization had

spent over US$1.2M for the soft-ware, implementation, and train-ing. This did not include the costs of actual implementation to their over 300 working professionals. They had purchased this very feature-rich PPM tool due to an associated organization’s pur-chase of the same tool so in order


Now that you have read and hopefully discussed how to de-sign and implement a PPPM vi-sion and road map at your organi-zation the next step is going to be the toughest since it involves the application of managerial or exec-utive will power towards the goals of your PPPM vision. Having worked with both private and public entities in their PPPM envi-ronment, some organizations begin with sound and well-meaning intentions with respect to desiring a PPPM solution but fail to follow through in several important areas. This column will deal with these in turn over the next few issues.

These areas of concern when implementing your PPPM are:

New policy and process disci-pline

Changing existing business pro-cesses

New tool and technique utiliza-tion

Changing of status quo atti-tudes

Utilization of new reporting and decision support information

Planning adequate transition time, and

Monitoring and adjusting PPPM over time

These areas are NOT evident in ALL organizations that implement a PPPM environment; however, in totality, they arise in different order, frequency, and intensity so

it is important that you under-stand their characteristics, evi-dence of existence, and how to resolve them if they do attempt to derail your PPPM efforts.

For this article, one of the most difficult concerns facing an organ-ization when implementing a business solution of the magni-tude that a PPPM environment will demand is that of obtaining the support of existing manage-ment and executive personnel in the form of discipline towards those for which the work of im-plementation will fall. In any new policy or process endeavor, the concepts of the new regime can be easily described in both its costs and benefits. The impact of its opportunity costs – that of not implementing the new policy or process – can even be made clear and understandable to the troops, so to speak. The real work begins with the first work effort that comes from the desire by the management and/or execu-tive team to move forward. This

effort will fall to those that may already see it as another “policy or idea de jour” that if ignored with sufficient dismissiveness, it will follow the other unsupported or skimpily implemented business programs they have seen from their management team.

While this is sad, it will only make your organization’s implementa-

“.difficult

concerns ..

obtaining the

support of

existing

management

and executive

personnel in the

form of

discipline

towards those

for which the

work of

implementation

will fall.”

PH Lohnes

MBA, PMP, MCTS

Featured Columnist

The PPPM Roadmap Project Management Discipline


P A G E 1 0 V O L U M E 2 0 1 3 , I S S U E 1 1

often does lead to the project losing its way as the motivation and assessment of requirements become murky. Only a clarifying definition of the funding entity’s ‘dissatisfaction with their status quo’ must lie at the heart of a project’s life force. So many IT projects are chartered, defined, and awarded without knowing what the business value or im-pact of the project’s deliverables will be when they are produced ‘fit-for-use’ for acceptance by the customer.

In many projects without the birthright of a business case anal-ysis or business problem defini-tion, the project requirements never seem to solidify to a point

of supporting the project’s work effort to produce the deliverables that will ultimately resolve the project sponsor’s or customer’s initial reason for providing the project’s budget. While this may seem laughable to most since the adage of “any well-healed cus-tomer is a good customer” espe-cially in this period of economic troubles, the use of an organiza-tion’s limited resources to pro-duce deliverables that are not

As many Project Managers (PM) and Business Analysts (BA) have received their initial training in the current bodies of knowledge for their respective disciplines, they are taught that the PM is assigned during the project char-ter or initialization phase of the project. While this may seem to make sense to assign and authorize the PM first, most of these traditionally instructed professionals fail to real-ize that the project does not truly begin with the charter or statement of work (SOW). All projects begin their life cycles as business cases or at least should in order to deter-mine the value the com-pleted project will offer the organization. So many projects are just chartered or awarded due to the backing of an influential sponsor or customer that is willing to fund the pro-ject.

The willingness to fund should NOT be the only factor on which the project’s value should be based, but unfortunately in these days of economic sourness, it is. Any project should be given the birthing process of a business case development and analysis regardless of who is willing to pay for the deliverables. A mere lay-ing down of funding without a true understanding of the reason for a project’s existence can and

truly in the key stakeholders’ best interests may set the organiza-tion back and not towards the achievement of strategic goals or horizons.

One very powerful and simple action that can assist in solving this rudder-less project is to as-sign the project’s BA during the business case or SOW develop-ment activities. The value of a truly professional BA is his/her ability to combine not only the understanding of project man-agement concepts, but more im-portantly during this pre-authorization stage is their under-standing of how the business itself will benefit from the resolu-tion of the business issue that

forms the impetus for the project’s creation. So many project teams become clueless dur-ing the throes of pro-ject execution as to the purpose of their involvement especially as teams are shuffled and reorganized during the long life cycles that most IT projects con-sume. Begging the question for longer instantiated or more permanent teams is discussed in the “In My Opinion” column of this month’s PPG. If teams were to be con-sidered longer lived than the project some of this temporary

mindset could be banished.

The pre-authorize assignment of the BA can provide the continuity that is lacking from the current hiatal chasm formed between the business case and the project proper. Most organizations do not involve their project manage-ment staff or resources in the design, development, or writing of a business case, and many do


The BA Forum: Assigning the BA First!

The Unknown

Business Analysis

(PPG Research Staff)

“In many

projects

without the

birthright of a

business case

analysis or

business

problem

definition, the

project

requirements

never seem to

solidify…”



we offer ourselves the possibility to take the time to notice our breathing. As we are focusing on our breathing, we magically loos-en up and build our personal sup-port which increases our percep-tion and option for viewing the situation with a new point of view and heightened empathy. This in turn enhances our propensity for influence and leadership. I might then ask an open-ended question. I avoid asking a yes/no question such as: "so do you agree with the pro-posed solution?" I also refrain from asking: "WHY don’t you agree?" WHY is a problematic word, as it carries a hint of blame to it and would intensify the conflict. I use

softer framing with the word HOW, such as: "HOW would you suggest continuing now?" Or alternatively: "can you offer us your per-spective?" And even: "I would like to receive your view on the solution." By stating what I want, I lead by example and create an op-

portunity for others to do the same. Many decision making meetings are at an impasse, as


Michael Nir

Renowned Author

Featured Columnist

Silent Influencing

Changing Difficult Settings There we go again, no raise. If only I knew how to get it right this time! Jennifer – the client does not agree to our terms – how can we influence him to sign the con-tract? Robert – there is no way the team will follow you – maybe you can show some leadership? Sounds familiar? From the denizens of corporate cubicles to the ever distressed

home business owner all the way to the supply chain, engineering, development, finance and mar-keting departments – knowing

how to influence can greatly im-pact your results. Let us review for example the following scenario: A tough colleague, who assumes a hostile, close position and is unwilling to join, collaborate, open up, and so on. Realistically, we are not always able to change such a position. However, there are tools and techniques to si-lently influence this scenario. When I encounter a negative-closed attitude where there is no cooperation, I appreciate that there is little use in continuing the interaction. Often, it is futile to work against powerful re-sistance. The first thing I do is slow down, take a breath and observe the process. Breathing is

a very important and often ne-glected remedy to overcome challenging scenarios. Awareness of a situation is heightened when

“From the

denizens of

corporate

cubicles to the

ever distressed

home business

owner…

knowing how

to influence

can greatly

impact your

results.”

Practically Proven



financial resources. Even if a project is well funded there may not be enough non-financial resources to adequately support a project’s suc-cessful completion. Money may not be the solution for a skilled labor shortage, unavailable infrastructure or a logistical delay in raw materials.

By the time the resources are recog-nized as being inadequate, the impact of the obstacle is already occurring. Timelines are missed and stress rises when project teams are forced to do

“more with less.” So why then would organizations knowingly put their new business initiatives at risk by getting rid of more people?

The environment may be such that a project being undertaken is so important to the survival of the enter-prise that there is no other way but to risk its failure by stressing the project through inadequate resource alloca-tion. “Better to have tried and failed, than never tried at all.” This approach is best described as a last ditch effort.

The risk of failure in some cases may be so high that one would question the via-bility of the project to begin with. This is a highly charged topic, and generated com-

mentary from across the spectrum of project team members including pro-ject sponsors, beneficiaries, and pro-ject managers. Project managers ac-customed to doing more with less are now being asked to do, “Much more,


Resources Not Adequate! * Resources are Inadequate (excluding funding) is ranked third as a cause of project failure globally ac-cording to the 2013 Global Survey, Top 10 Obstacles to Project Success. This article is meant as a precursor to more in depth information regarding the; causes, impacts, early detection, and mitigation of this complex and often misdiagnosed project obstacle. The additional information can be found in this issue of the Post-Gazette’s Supplement on page ##.

Given current events, it is interesting

to note that the obstacle known as Resources are Inadequate (excluding funding) has risen in rank from #5 in 2008, to #3 by 2013 on our annual survey of the Top 10 Obstacles to Pro-ject Success. Results indicated that almost one out of every two projects

is impacted by this obstacle.

In the current global economy many companies have been forced to re-duce their labor resources through lay-offs. Companies using lay-offs as a strategy to control costs, put their project based investments at risk. Simply put, these projects no longer have sufficient skilled resources and risk successful completion.

This obstacle existed in our 2008 sur-vey before significant layoff activity

occurred. This indicates that the Re-sources are Inadequate (excluding funding) obstacle is not exclusively driven by the state of the economy. The reason a lack of funding is exclud-ed from this obstacle is due to the difference between non-financial and

MuTo Performance Corp - 2013 Survey Forum



There are less than 60 days left in this year, and for the past 300 days or so, I have been on a cru-sade to empower project manag-ers (PM), especially IT PM with the equipment they need to be-come more agile, smarter and more developmental than they have ever been. I have givens keynotes, written more articles and blog posts, and developed more programs to help this crowd mas-ter success at taking the reins of leadership within their respective teams.

I have noticed an un-dercurrent, a pattern of sorts within the 2,500 people I have worked with this year. There are a set of themes that continue to plague IT profes-sionals when it comes to delivering success-ful projects and devel-oping their teams in the process. These three items some-times hinder progress, dismantle teams, or remove smart people from organizations – they are detrimental!

No more suspense, here they are:

Fear #1: The “IDKE Syndrome”. From new team leaders to new PM, I have witnessed more than 70 new project managers admit, “I don’t know enough . . .” to lead this team, to manage this large project, to lead this organization.

I call it the IDKE (I Don’t Know Enough) Syndrome, and it runs rampant at all levels of an organi-zation. How do you overcome this epidemic? When properly analyzed, it is a two-fold answer.

First, understand that no time is the right time. You will never be developed enough, equipped enough, trained enough. Actually, the transition is part of your de-velopment. Get comfortable with the unknown.

Secondly, you must take charge of filling the gap in your develop-

ment. If you need more training, get it. Take a weekend course to learn ITIL. Go to a PMP® Boot camp and get it over with. It is just that simple. I was recently interviewed by a firm to conduct a series of webinars for their partner organizations. Did I know all of their issues? No, but I learned them over a weekend via my girlfriend, Ms. Google. My

willingness to put in the work to understand their issues earned me a contract. So can yours.

Fear #2: Changing with the Ani-mals. Let me say it once and for all: The PMBOK® Guide will not tell you, PMI will not tell you, your project sponsor will not even tell you, so I will: there will be changes in the scope, budget and schedule of your project! It is like there will be change in your team before it is all said and done, too! Can it be managed? Yes and No. Let me explain. Since you now know to expect it, it is

not such a big deal any-more. Learn to adapt quickly, while keeping the general pro-ject bounda-ries. Adapt to the different animals work-ing on the project. I say animals be-cause, do not our project team mem-bers take on animalistic qualities un-der strict

deadlines?

Some leaders become demanding gorillas. Happy flamingos gather to discuss project successes at happy hour after work. Flexible chameleons can go either way. They adjust very well, but usually are frustrated by their lack of making a decision. And our pro-


The “Consultant in Jeans®”

Chris Daniel

PMP

Featured Columnist

“What would

you do with

this project if

you could

NOT fail?” It

presses you to

search the

innovation lab

in your mind

to uncover

new

thinking…”

Overcoming the IT Project Manager’s Top Fears The 3 Terminal Fears & Their Solutions



In My Opinion

As the introductory piece on the editorial page laid out the issue, I am going to dissect the problem, issue, and solutions to this road-block that has been plaguing the project management (PM) and business analysis (BA) disciplines for most of the modern PM era – that is from about 1970 forward. This problem is the continued and blinded acceptance that pro-ject teams must be temporary like the projects to which they provide intellectual and skilled human resources. However, such dogged following of principles without determining their impact perpetrates, in my opinion, the ineffective development of pro-ject team building and cohesive-ness that comes from utilizing permanent project teams.

Yes, I know that I am talking here-sy to many in the PM standards community and those that ad-here to their dogma; however, for one that has seen the chaos, poorer performance, and simple waste of resources, the time has arrived to bring into the light of open discussion regardless of the consequences and flames I will likely subject myself to along with the PPG. This cannot be helped nor will it deter me from bringing such PM&BA principles and pro-cesses to light so that we can bring our disciplines into the cur-rent century while providing our industries with the modern tools needed to deal with projects and programs that are increasing in complexity and visibility.

The latest front page failure of project management that is dam-aging and hurting all of us in the PM&BA profession is of course the very public and so preventa-ble failure of the touted roll-out of the US Government’s healthcare.gov web site that was to provide a “Yahoo or Kayak type” experience in shopping for and obtaining government man-dated healthcare policies. This failure more than any other of recent current events will cast a shadow over the ability and skills of professional PM&BA since the

design, development, and deploy-ment of web sites up until this time was taken as almost axio-matic given the number and more complex web site available in most other areas of human endeavor. Why was this particu-lar web site so difficult to design,

implement, and roll-out?

In my opinion, I am going to offer a basis for the problem that lies at the heart of most IT projects – the use of temporary project teams. While I am sure that there are many that are now shutting down the PPG, throwing their coffee cups at the screen, shouting in an effort to reach my ears, and other forms of anger and derision. If you have just completed one of these forms of sensitivity touches, as I call them, you might ask yourself, why is the offered idea so powerful to evoke

such a response? From the Bard of Avon, “Me thinks, he does protest too much…”

To begin our discussion, the problem must be clarified along with all the attendant problems and inefficiencies. Not to be one sided, the positive side of tem-porary team utilization will be described completing the dis-cussion. The concept of tempo-rary team is lost in the annals of modern age project manage-ment team definition since I cannot find any specific refer-ence to where the use of tem-porary team is either mandated or required. Let us make it easy for our purposes that temporary teams flowed from one of the characteristics of projects: the temporary life frame of all pro-jects that produce unique “fit-for-use” deliverables. Since pro-jects are temporary or finite

then project teams should proba-bly exhibit the same characteris-tic. When the project is closed, the team breaks up and goes their own way. However, a better explanation may be in order.


“Yes, I know

that I am

talking heresy

to many in

the PM

standards

community

and those

that adhere

to their

dogma…”

By Paul H. Lohnes PMP, MBA, MCTS

PPG Editor-In-Chief

The Current Bodies of Knowledge Must Change!



dump. Such a sad and currently unfinished ending, but now the emotional rollercoaster has come to a complete stop.

The point of this ridiculous anec-dote is that things are not always as they seem. Problems have an appearance like an onion. They have different layers that can be peeled away to reveal the same looking onion. And sometimes peeling and digging deeper to the foundation is necessary in order to find a solution rather than fix-ing an outer layer problem that does not solve what is actually causing the issue in the first place, like with me trying the vari-ous solutions that were offered by other computer owners that have encountered the same sys-tem file error in their technology travels. When there is an issue

that impedes growth or progress, in looking to fix it there will be many different solu-tions that have worked for different people. But the problem is not necessarily the same; it just looks that way on the outside. Once a problem is examined further, where the roots can be discov-ered, a solution be-comes much more specific.

It seems obvious when explained so redun-dantly, pretty basic and elementary stuff. But my computer’s ongo-ing saga has gotten me thinking about bigger situations. Most spe-

cifically is my employment search since graduation. I am coming up


Brandon Lohnes

BA, MBA

Featured Columnist

Fixing the Wrong Problem!

Have you ever encountered prob-lems with a project? Or maybe run into a speed bump in your personal life, or with your com-puter? No, no, of course you have not. But for fun, let us as-sume that you have. And for even more fun, let us keep that in mind as we poke fun at me and my recent experience. And hope-fully I can make a point or two along the way for good measure.

So recently my computer came under siege. The hilarity of the situation is that I was attempting to reinstall the updater for my computer security and inadvert-ently contracted a Trojan mal-

ware because I went searching for a solution in the wrong place, so it would seem. This whole

situation is completely my fault, queue the pointing and laughing. Anyways, after jumping through the hoops to get that cleaned off of my computer I was left with a lingering issue. My computer now has a system file that has become corrupted so certain pro-grams will not run. I proceeded to delete numerous applications and reinstall them, I tried up-dating the originating program that the file is derived from, rein-stalling system drivers, and sever-al other “home remedies” sug-gested by others in the blog-osphere that have come across similar issues. These did not work for me because I was fixing issues that did not exist. My is-sue was still at large. So I have reached a concluding resignation after further researching that the

original file has to be reinstalled from my system’s OS disk, if not the entire OS after a system

“The point of

this ridiculous

anecdote is

that things

are not

always as

they seem.

Problems

have an

appearance

like an

onion.”

Testing the Waters



PH Lohnes

MBA, PMP, MCTS

Featured Columnist

Critical Chain vs. Traditional Project Management, Part 1

Before moving on from this arti-cle thinking that it concern sched-uling somehow, STOP! These se-ries of articles are about the utili-zation of critical chain in manag-ing projects not simply the focus of critical chain as a replacement for the well-known and often misused scheduling technique of the critical path method (CPM) that is the darling of most self-proclaimed project management standards setting bodies today. Most if not all of the bodies of knowledge that are taught to and used by a predominate number of professional Project Managers (PM) teach that the CPM is the correct form for managing a pro-ject via the project schedule. This article attempts to even the score by discussing an alternative man-agement technique or methodol-ogy as you wish that can provide a more realistic perspective on a project’s reality – making the reporting of a project’s progress more in alignment with actuals and not guesses.

The concept of critical chain pro-ject management (CCPM) was first hinted at in a most unlikely venue – the business novel, “The Goal”, written by Dr. Eliyahu M. Goldratt who later extended the details of the technique in his subsequent business novel,

“Critical Chain.” Both these most published works have been large-ly ignored by the project manage-ment discipline since the current most accepted body of knowledge, the revered Project Management Institute’s Project Management Body of Knowledge, 5th Edition also known as the PMBOK® Guide gives only a pass-ing mention of the critical chain concept after full exploring and discussing the more acceptable CPM. However, the PMBOK® Guide does not mention or detail the severe assumptions and thus drawbacks of the CPM that was developed during the 1960’s by the US Navy before the wide spread use of computers or even capable hand calculators. This is significant since the assumptions that are made in the use of the CPM stem from the limitations of calculations of resource utiliza-tion that would have been labori-ous at that time.

Therefore, it is necessary to un-derstand the assumptions and weaknesses of the CPM before the true value of CCPM can be appreciated. Now please do not dismiss this idea before you have fully read and understood these issues since a person with a closed mind is a person with a limited future. Growth demands a sense of interest, curiosity, and wonder at those things not fully within the grasp of the individual under expansion. As CJP Stone-man has been often quoted on this matter says, “A closed mind fathers a limited existence.” In other words, a closed mind limits one’s ability to progress and achieve. So, consider that the concept of the CPM that you have been taught without truly understanding its limitations or assumptions may not be serving your project success rates properly.


“The concept

of critical chain

project

management

(CCPM) was

first hinted at

in a most

unlikely venue

— the business

novel, ‘The

Goal’”

The Well-Skilled PM



With the vast changes in regula-tory compliance today in the US (United States) it is important for organizations that are required to adhere to regulations to do their “due diligence” when docu-menting internal and external policies and controls, assigning appropriate compliance manage-ment oversight, and ensuring compliance through employee training.

These compliance regulations be-come even more challenging when implementing them within Infor-mation Technolo-gy (IT) compliance controls. IT com-pliance programs (C&E) are difficult to implement be-cause they touch so many areas within an organi-zation. One way to ensure a suc-cessful IT compli-ance program would be to cen-tralize the compli-ance function within the organi-zation to be able to provide continuous oversight across all areas that they apply to. Organizations need to com-municate new regulations and reinforce current regulations to employees on a continuous basis to be effective in developing a higher level of ethical and lawful conduct within their organiza-

tions. It really should not take the threat of conviction on federal statues, including fines and resti-tution, imprisonment and proba-tion or exclusion from participa-tion in various federally funded programs for organizations to implement strong internal con-trols, but somehow this does happen.

Previous PPG articles have talked about the 1991 United States Sentencing Commission (USSC) Organization Sentencing Guide-lines. The USSC developed the guidelines to promote consistent

treatment of organizations (and individuals) convicted of these crimes. These guidelines assist in the model for compliance pro-grams today and actually help set the criteria for executives in setting up their C&E programs. In past PPG Compliance Central arti-

Cheryl A. Wilson

PMP, PMI-RMP, CCEP

Featured Columnist

cles, we discussed the seven core elements the Sentencing Guide-line uses as their model. Accord-ing to the USSC, an organization that has an effective compliance and ethics program can mitigate their sentences if they have fol-lowed through with imple-menting and maintaining a set of standards demonstrating an effective C&E program much like the set of seven standards set forth in the USSC.

Research has shown the organiza-tion that maintains USSC struc-tured C&E programs could reduce

fines for a crimi-nal conviction by as much as 90%. BUT, having a compliance pro-gram does not excuse the crime, but shows that the organization took reasonable efforts to pre-vent, detect and correct any im-proper conduct to deter the crime. A good C&E program may lower the organization’s starting “culpability score” by 60%, but not having a C&E program is actually consid-ered a negative factor which

increases this culpability score.

However to have an effective C&E program, organizations need to exercise their due diligence to try and prevent and detect criminal activity. The compliance program should be designed to encourage


Compliance Central

IT Compliance—Risk Assessment & Oversight

“Research has

shown the

organization

that maintains

USSG

structured

C&E programs

could reduce

fines for a

criminal

conviction by

as much as

90%.”



PH Lohnes

MBA, PMP, MCTS

Featured Columnist

The Project Whisperer Rescuing an IT Project, Part 1

In concert with the PPG’s month-ly theme of IT projects, the Pro-ject Whisperer (PW) concentrates its focus on how to rescue an IT project. The manner in which this engagement is approached will determine the viability of the project rescue suggestions as to the recommended outcomes. We have discovered that if the ap-proach is incorrectly handled, the suggestions can be dismissed or worse, thwarted by those that have a vested interest in the res-cue not being effected.

What is meant by this is with ANY attempted project rescue there will be those stakeholders that desire to see the project contin-ued regardless of current status and those that desire to see the project terminated unceremoni-ously. The PW must uncover sev-eral important parameters BE-FORE any attempt at determining the efficacy of the attempted remediation. To unknowingly become the pawn of either of the aforementioned stakeholders will reduce the objectivity of the PW in accurately and correctly diag-nosing the underlying issues and then developing the most appro-priate adjustment or termination actions needed to meet the con-structs of both the client and pro-ject.

In beginning any project whisper-

ing engagement, the PW MUST ensure he/she has a firm grasp of several very important engage-ment characteristics:

1. Who is the stakeholder(s) en-gaging the PW?

2. What are their acceptable outcomes?

3. What has been communicated about a rescue attempt to the existing project stakeholders including the project team itself?

4. Will the project continue exe-cution during the attempt?

Before investigating the project’s conditions, the clarification of these parameters are necessary to ensure that the PW does not step on any hidden landmines that may end the whispering attempt before it gets started. Also, depending on the answers to the above questions, the con-sulting PW may wish to pass on the engagement. Each of these questions need more clarification for the PW just beginning their career, and can be used by expe-rienced PW to determine if they are accumulating the necessary pre-attempt information in order to maximize their chances for success.

First, knowing who is engaging you, the PW, is paramount since anyone of the KEY stakeholders with funding sources could seek to hire a PW for a project on which they are both highly inter-ested and most impactful. Re-member that an initial stakehold-er analysis may need to be done to discover the stakeholders that are both highly interested in the outcome of the project (before the remediation), and if they are effectively able to carry out or have implemented your recom-mendations.

One of the primary reasons for engaging an external PW is that either no one is trusted to pro-vide a truly objective analysis of the project’s future or ability to be remediated, or that using an outsider gives cover to the inter-nal team members and stake-holders if the whispering analysis produces negative assertions or uncovers weak project manage-ment. By any definition of project whispering and regardless of or-ganizational policy, the LAST per-son that should be engaged to accomplish a project whispering should be ANY of the project’s key stakeholders. This list in-cludes any member of the cur-rent project team, project spon-sors, customers or organizational management. The bias that these listed stakeholders would bring and be completely powerless to overcome would be significant enough to render the whispering suggestions useless or at least tainted. The last consequence the results of an already charged situ-ation would need is the arguing over the recommendations as to the actions required to save a derailed or dysfunctional project. Such wasted energy would al-most certainly doom the project to the scrap heap. Thus, only an external or sufficiently independ-ent internal PW should be utilized whom should report to the pro-ject sponsor directly.

Another aspect of knowing the engaging stakeholder(s) assists with answering the second char-acteristic: what are the accepta-ble outcomes of the whispering analysis? Initially this question may seem quite absurd, but real-ize from an old adage, “all that glitters is not gold.” The reason for the whispering may appear at


“We have

discovered

that if the

approach is

incorrectly

handled the

suggestions

can be

dismissed or

worse,

thwarted by

those that

have a vested

interest in the

rescue not

being

effective.”



The Master Scheduler Agile versus Waterfall Scheduling

Fast-paced, market-focused, lean and agile, that is today’s cutting edge software development. Getting software out the door fast with functionality, then work the bugs; that has been Mi-crosoft’s game plan for years. The marketplace calls it ‘Agile’. Perhaps one of the greatest re-

cent example of software devel-opment is none other than our very own ‘healthcare.gov’. What do we see there? A political hot-potato assuring all eyes are trained on whether the US Gov-ernment could actually create and maintain a totally functional healthcare sign-up website ser-vicing tens of millions. We all

know what happened. Since I am not an insider into the debacle that occurred and is still occur-ring, I can only speculate that Agile was not the spoke that turned the website wheel.

Functional testing occurred late in the game – too late in fact to ensure that all went smoothly. Now tens of tax-payers’ millions are being spent to get the ‘David Ortiz’ hitters in the game and salvage the website and dozens of reputations.

So let us talk about Agile, what it is and how if differs from tradi-tional waterfall. According to Webster’s, agility is the ability to move quickly and easily. Let us

begin with the ‘Agile Manifesto’.

The Agile Manifesto states:

1. Individuals and interactions over processes and tools

2. Working software over com-prehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

The manifesto implies that while there is value on the right side of the phrases, the values on the left have higher value. Agile is the left side values/ waterfall, the old-school, to-the-right. Ok, great. What we are hearing is Agile gu-rus want us to ‘evolve’ from ty-rannosaurus rex to road-runner. Get ‘functional’ software out the door fast – not a complete overall product, just bits and chunks of functional software building on itself.

The list below provides some of the distinguishing differences between Agile vs. Waterfall ap-

proaches:

Agile / Scrum Method-ology

Fast-paced.

Evolving scope (one of PMI’s Holy Grails violated?)

An incremental ap-proach to work (short time-box)/ immediate feedback from the customer.

Work begins with a short-term planning effort.

Requires buy-in from all business interests since they will be inti-mately involved in the process.

No project life cycle required.

Sprints rule (about 2-4 weeks), which provides opportunities to make multiple corrective ac-tions during iterations.

Business / technical members are co-located and work to-


“The (Agile)

manifesto

implies that

while there is

value on the

right side of the

phrases, the

values on the

left have higher

value.”

Barry E. Clark

PMP, PMI-SMP



We have reported that the pro-ject failure rate for IT projects has increased over that past 2 dec-ades. Currently, surveys put this failure rate somewhere in the range of 70% of all IT projects fail for one reason or another. In fact, recently, a newscaster re-ported that the errors on the website for the Affordable Care Act were normal as “All IT pro-jects usually fail.”

Why should we accept project failure as the norm for our pro-

jects, and thus lead us to ask the related question, “is poor project management ethical?”

Failure on IT projects can be

avoided by understanding the concept that MCLMG calls “Deliverables Centered Project Management”. While many pro-ject managers (PM) know that a project has deliverables, many do not understand their importance and central preeminence. Deliv-erables are the only reason for a project to be chartered or brought into existence. Without deliverables, there is no project. Therefore, since deliverables are the reason for projects in the first place, how is it that some project teams do not know what are the deliverables of the project to which they are assigned?

It then becomes the responsibil-ity of the PM to ensure the team knows what the deliverables are towards which their efforts and

skills will be directed. The first action taken when a project is in trouble is to revisit the delivera-bles to determine if the project is following the plan towards the

The Line in the Sand

Cheryl A. Wilson

PMP, PMI-RMP, CCEP

Featured Columnist

production of the projects “fit-for-use” deliverables.

Incompetent project manage-ment leads to confusion from team members, unclear direction and eventually troubled projects. Knowing the projects deliverables and constraints seems like a basic part of good project manage-ment, right? It is actually more common than you would think that an inexperienced PM does not know what the basic parts of the project are.

One reason this happens is many inexperienced PM get too caught up in the details and never look up to see the big picture -- the reason for the project to exist in the first place.

All projects have the following attributes:

A definite timeframe for its completion,

Confinement by primary con-straints (scope, time, cost, quali-ty, and risks), and

Requirement to produce unique, “fit-for-use” deliv-erables.

This definition is a more specific than most bodies of knowledge currently utilize; however, it covers all the true and mature aspects of projects as they are implemented

today. The attribute that is left out from most definitions is the second one of being confined by the project’s primary constraints.


Is Poor Project Management Ethical?

“Why should

we accept

project

failure as the

norm for our

projects…?

“It then

becomes the

responsibility

of the PM to

ensure the

team knows

what the

deliverables

are towards

which their

efforts and

skills will be

directed.”



In researching this article, the Project Eye (PE) is overwhelmed as where to begin or even layout the contention that Government IT projects have a very high fail-ure rate. Initially, the PE was go-ing to limit its search and discus-sion to just the failed IT projects on the west side of the Atlantic; however, when doing its search for foundational material, the PE was flabbergasted by the failure of government IT projects across the world from the UK to Austral-ia and from the US to Malaysia. It is definitely not just a US Government (USG) problem, the PE has discovered, but a problem on all continents and in all languages. Even the United Nations has published a scathing report on the failure of eGovernment pro-jects. The PE has dis-covered that the swath of mayhem and destruction is widespread and prev-alent – it appears to know no national or what on the surface appears to be sophis-tication of the gov-ernment’s technology reputa-tions.

The PE has a bevy of articles, sta-tistics, and revelations concerning the failure rates of government IT projects from sources including

governments’ own audits, world renowned consulting firms, and well-known IT newspapers. The PE will list just a few for coverage of the topic:

1. Corporate IT lawyer, Alistair Maughan in a Computer Weekly guest article states that even Agile-based IT pro-jects are susceptible to spec-tacular failures based on the fundamental aspect of Agile that loosely defined require-ments and roles are better for IT projects than the more for-mal or traditional approach of heavily planned and detailed requirements gathering ac-complished up front. He states this certainty for four (4) rea-sons:

a. Government customers want to know up front the

system costs – Agile deliv-ers incrementally

b. Government must follow open bidding procurement rules – Agile does not sup-port such comparisons

The Project Eye

PPG Investigations

Reporting on the seedier side

of project management

c. Government desire pre-scribed remediation pro-cesses – Agile does offer such planning options

d. Government is centrally organized and managed – Agile is based on mutually agreeable decision making

2. PublicTechnology.net re-porting about failed Australian government Information Com-munications Technology (ICT) projects related that “successful delivery of major ICT projects seems to have become ‘beyond the wit’ of government despite decades of development of project and systems development meth-odologies, gateway reviews, risk-management and pro-curement frameworks, and major project governance

processes.” When auditing 10 of the larg-est in-flight ICT-enabled projects fund-ed between 2003 and 2007, all of the audit-ed projects (100%) failed to meet expec-tations and were on average 100% OVER BUDGET! The report continued to point out that two (2) were 3 times over budget and many failed outright after a consumption of over AU$100M of gov-ernment funds. The audit pointed to the diffusion of accounta-bility in government

ICT projects while at the same time these projects had be-come core business functions in the private sector.

3. Bluewolf.com reporting on the


High Failure Rate of US Government IT Projects

“...the PE was

flabbergasted

by the failure

of

government

IT projects

across the

world from

the UK to

Australia and

from the US

to Malaysia.”



Have you noticed that working and thriving in today’s economy is different? Since the recession of 2008, almost five years ago, the U.S. economy is still growing but slowly and at a snail’s pace.

Our Country’s high debit, the Federal Government’s budgeting uncertainties, the recent Govern-ment shut down have all caused a domino effect throughout our economy resulting in trepidation, hesitation, fears, and even paralysis with moving forward with organizations’ busi-ness and revenue goals. More im-portantly, these are unprecedented times in our country with politics and never before has our coun-try been so divided with the direction of organizations’ mis-sions, budgets, pro-curements and priori-ties. Welcome to our new normal!

In a recent article written by Kimberly Amadeo who wrote ‘Top 5 Economic Trends: What is the Future of the U.S. Economy?’[1] I be-lieve everyone no matter where you are located can at least relate to one if not most of these evolving trends the Ms. Amado captured.

1. “Uncertainty Raises Business Costs:” the old way that busi-nesses brought in their reve-nue is no longer successful so business have to change the way that they do business if they are to remain competi-tive in today’s market.

2. “Companies Stick with Free-lance, Temporary and Part-time Workers:” to lower op-erating costs business are re-ducing their overhead and working with self-employed, temporary or part-time work-ers.

3. “Baby Boomers Won't Re-tire:” the older work force is delaying retirement due to housing market, providing for other family members, inter-

ruptions with furloughs or lay-offs and they cannot afford to retire.

4. “Gradually Declines in Global

Shelley A. Mitchell

Shelley A. Mitchell

PMP, PMI-RMP

Guest Writer

Economic Power:” the de-mand and supply of products is shifting resulting in less rev-enue and changing American’s reputation as an economically powerful nation

5. “The U.S. Will Have another Major Crisis, But Avoid an Economic Collapse:” if our leaders do not work together we have the potential for an-other government shutdown. Hopefully not but the worry and concern is detrimental to our workforce.

From the Nation’s capital, the majority of beltway companies depend on contracting with the US Government and there has been a huge gap in the govern-ment issuing contracts. Although

most corporations have invested resources, time and effort in re-compete preparation; unfortu-


The New Normal!

“Welcome to

our new

normal! With

so much

uncertainty

businesses are

trying to do

more with

less!”



Two years ago, the UK govern-ment published a new infor-mation and communications technology (ICT) strategy, one of the key aims of which is to reduce the risk of ICT project failure within the public sector. One essential element of the strategy is the adoption of agile project methodologies instead of the traditional “waterfall” approach to big software development ex-ercises.

Fast forward to 2013 and there seems little outward signs of suc-cess. In particular, Universal Credit, a £2 billion flagship welfare reform project by the Department for Work and Pensions, was the most high-profile adopter of agile; but has now ceased all agile software devel-opment work.

So what is the prob-lem? In my view, the core issue is that agile methodologies are ill-suited to government ICT projects. But the reason for that is more down to fea-tures of the public sector environment than deficiencies in an agile ap-proach. The way that Govern-ment is organised to deliver pub-lic services is not conducive to an agile approach, and the public

sector environment leaves agile processes little chance of being adopted properly, let alone ap-plied widely.

Under an agile methodology (as opposed to the more traditional “waterfall” methodology), an ICT project is developed flexibly and iteratively, with more direct cus-tomer involvement, and enabling quicker response to changing customer requirements. Agile projects are characterised by ac-tive user involvement and close customer collaboration; require-ments are developed iteratively and often only emerge gradually during a project; and customers pay for a certain level of resource commitment.

Agile projects tend to draw evan-

gelists who argue fiercely that waterfall projects are unrealistic and too often fail to meet expec-tations because of the sheer size and scope of the required deliver-

Alistair Maughan, Esq.

Alistair Maughan, Esq.

Partner, Morrison & Foerster

Guest WRiter

ables. They argue that customer and supplier ought to plan for success not failure, and engage on an ICT project as a joint enter-prise. They stress close working and collaboration, and the joint, gradual production of require-ments on a just-in-time basis. Particular features of agile pro-jects include the lack of clearly defined project roles for custom-er and provider, and the absence of immutable, fixed require-ments.

At one level, I agree with the agile evangelists – and, indeed, the UK government’s ICT strategy docu-ment – that, if all goes well, an agile approach can materially reduce the risk of project failure. Unfortunately, a number of is-

sues in the public sec-tor environment would need to be changed in order to allow success-ful adoption of agile approaches in the world of government ICT.

Firstly, someone needs to work out how to make agile work within the scope of a regulat-ed public procurement regime. Government is legally required to fol-low open procurement rules, which mean comparing offerings from different bidders on a like-for-like basis and choosing the one that offers best value for money. Under ag-ile, there is a less clear specification of outputs

up-front and often no definitive price. So how are government bodies supposed to comply with the legal requirements on open


How Agile Will Fail Government IT!

“Agile

projects tend

to draw

evangelists

who argue

fiercely that

waterfall

projects are

unrealistic

and too often

fail to meet

expectations

…”



The Buffer Zone The Answer Block

Oct’s Crossword

Puzzle Answer

Oct’s Sudoku

Puzzle Answer

Oct’s Chess Answer & Board at Game’s Start (note Oct Start)



“Enjoy a little

down time or

diversion to

refresh the

cognitive

abilities.”

— CJP Stoneman

Answers next month,

of course.

The Buffer Zone



Answers next month,

of course.

The Buffer Zone II

For you Sudoku fans.

For Chess fans. Each month a new chess teaser will be

provided. ———————-

White moves to gain an advantage. What is White’s BEST move?


Current Events


When I start working with any new client to help them set up their Com-pliance and Ethics Environment, I emphasize that my job is to help them avoid their organization from being on the front page of the news surrounded by scandal. Most clients are startled by my candor, but soon realize that I am not joking.

I wonder if the leaders of the Internal Revenue Service (IRS) thought of what the headline would be for their part in the targeting of their fellow Americans for exercising their free-dom of speech.

The Daily Mail of the United Kingdom reported that Danny Werfel, the in-terim director of the IRS who was appointed to clean up the agency, said “the IRS used a system of 'be on the lookout' lists with specific words and phrases to select politically-oriented groups to receive extra scrutiny before they could receive tax-exempt status.”[1]

Most of us know the story, but as part of the fallout, the published a 83 page document by Daniel Wefel, “Charting a Path Forward at the IRS: Initial Assessment and Plan of Action,” in June 2013, was written in response to the allegations that the IRS knowingly mislead Americans about the targeting of those con-servatives and Tea Party groups in their applications for tax-exempt status. Mr. Wefel wrote the publica-tion when he was the acting adminis-trator after Steven Miller, the IRS commissioner that resigned May 2013 after the news became a scan-dal. Wefel’s article, which is meant to be an outline for changes to en-sure IRS accountability, reports a number of important findings, ag-gressive actions, and next steps We-fel feels should put the IRS back on track.

Highlights of, “Charting a Path For-ward at the IRS: Initial Assess-ment and Plan of Action” are:

1. Accountably

2. Fixing the problems with the re-view of applications for tax-exempt status, and

3. Review of IRS operations and risks

Mr. Wefel served until John Koskinen, a veteran of government service was appointed by President Obama. Mr. Koskinen will serve until his term ends, November 12, 2017. Daniel Wefel was quoted in many news articles to be non-partisan and professional even if he was (as they say) someone inside the White House and might have been seen as a leader of an already distrusted agency.

It is important to know that prior to this document by Mr. Wefel, in May 2013, the Treasury Inspector General for Tax Administration (TIGTA) pre-pared an audit report that indicated there were significant management and judgment failures within the IRS

that contributed to the inappropriate treatment of American taxpayers applying for tax-exempt status. As with any organization that is found guilty of misconduct, an investigation was launch to identify the individuals within the IRS that targeted these specific groups. However, this inves-tigation, being conducted by the

IRS themselves, reported to have revealed “no signs of intentional wrongdoing by IRS personnel or in-volvement by parties outside of the IRS in the activities described in the recent TIGTA report.”

The three part report by Mr. Wefel and his team was part of the Secre-tary of the Treasury’s request for a “30 day” update on the progress within the IRS. The report starts out admitting both organizational and individual failures within the IRS and states the IRS Mission Statement:

“To provide America’s taxpayers top quality service by helping them understand and meet their tax responsibilities and enforce


The IRS Tax Exempt Scandal

PPG Research Staff

http://www.irs.gov/file_source/PUP/newsroom/Initial%20Assessment%20and%20Plan%20of%20Action.pdf






http://www.irs.gov/uac/Newsroom/Report-Outlines-Changes-for-IRS-To-Ensure-Accountability,-Chart-a-Path-Forward;-Immediate-Actions,-Next-Steps-Outlined





the deadline date. Given the current success rate so far this enrollment goal is highly unlikely. Due to the pub-lic frustration, lack of remediation, and inability of those wanting to en-roll, but are not able to, the number of enrollees will most likely be far

less. This condition is pushing the USG to provide an extension or delay to the deadline for enrollment or obtain-ing of healthcare coverage as even prominent members of the current US President’s own party are not calling for such an action. Just as the PPG was going to press, the US White House announced modifications in their own ACA that may allow policy holders the ability to return to their once cancelled healthcare policies under the new regulations. More on this later.

This situation has the makings of what is called in the aviation industry – a death spiral. As the conditions that are causing the situation to worse do in fact occur, the situation feeds on this lack of performance and like a plane that has lost adequate airflow over its wings, begins a spiral for which the pilot’s instinctive reactions only worsen the plane’s in-flight atti-tude causing additional loss of lift, a tightening of the spiral until the inevi-table occurs – a death spiral to earth. There is little to suggest that the cur-


The very public and dramatic failure of the US Government’s (USG) roll-out of the its Patient Protection & Afford-able Care Act (ACA) web site called healthcare.gov has been played out on almost eve-ry television, Internet blog, and social media providing the world with a view into the inability of govern-ments the world over to implement successful IT projects regardless of the amount of funding, or time to complete. The ACA is potentially the largest regulatory and impactful piece of legislation passed in the USA to date. It has the potential to swamp the costs of the USA’s So-cial Security, Medicare, Medicaid, Prescription Drug, and Food Stamps programs combined by attempting to manage over one sixth (1/6) of the gargantuan USA’s annual Gross Domestic Product of over US$16 Trillion for 2013 according the recent World Bank figures. This means that when the ACA completes its roll-out over the next few years it will account for over US$3 Trillion in ex-penditures.

Healthcare in the USA is close to twice (2X) the percentage spending in the UK, and is sometimes three to four (3X to 4X) the spending of most indus-trialized nations. Thus the USG’s Health & Human Services Department (HHS) via its Centers for Medicare & Medicaid Services (CMS) will attempt to control the largest global budget for any single expenditure surpassing the massive USG’s own Department

of Defense (DOD) annual budget of a mere US$525 Billion or 3.4% of US GDP making healthcare legislation and regulation over four (4X) the size of the USG defense direct expendi-tures. Impressive to say the least.

With this almost unbelievable amount

of spending for a single aspect of the USA’s domestic life style, this recent and dramatic failure of its healthcare.gov launch makes the numbers all the more incredulous. To date according to the USG’s only in-ternal, but only recently publicized numbers, only about 50,000 US citi-zens have been able to register for healthcare policies (note registered, not obtained) via the web site. Even with the additional over 13,000 staff members projected to be needed in the now eight (8), but soon to be six-teen (16) contact centers operated by the Vangent subsidiary of General Dynamics Information Technology, the registrations and policies being handled are miniscule compared to the over 7 million policies needed to be in place by March 31, 2014 as stat-ed by the HHS/CMS division and re-peated by the White House press sec-retary, Mr. Jay Carney.

Calculating the number of enrollees needed by March 31, 2014 as 7 mil-lions compared to the only 50,000 currently, the USG will need to enroll over 51,800 per day from now until

Current Events The ACA Web Site Launch

By PPG Research

Staff


Goal of Risk Assessment & the RBIA


In the Compliance Central article this month; [add link] “IT Compli-ance - Risk assessment and Over-sight” I talked about managing risk in an IT environment and how to set up an IT risk assess-ment and a Risk-based internal

audit within your organization’s Compliance and Ethics (C&E) pro-gram.

This article will go into a more in-depth look at the benefits of:

The Traditional approach versus the Risk Based Internal Audit (RBIA) approach

Risk assessments at the organi-zational level, and

Risk - Based Internal audit (RBIA)

Risk assessments at the organi-zational level address the busi-ness unit areas that could affect the strategic goals and objectives from the organizational perspec-tive. Conducting a risk assess-ment at this level is the first step in preparing the organization for a risk based internal audit (RBIA).The RBIA is an internal audit based on the consideration of strategic goals and objectives

and potential risks that could affect the organization from achieving their goals. During the risk assessment phase, organiza-tional risks are identified, as-sessed and prioritized into busi-ness unit areas within the organi-zation. Risk assessments should be done at least annually, but MCLMG recommends a quarterly review of all regulations and

mandates to see how they affect the organization.

The goal of the organizational risk assessment is to identify the true risks in the organization based on the organization’s strategic goals and objectives. (Remember, risks are tied to the deliverables or in

this case, the strategic goals and objectives). As a review, the

definition of a risk is defined as an uncertain future event. Each risk potential has the probability of a negative impact on the suc-cessful production of the organi-zation’s strategic goals and objec-tives. All risks except those that source from a systemic environ-ment should be tied to these goals and objectives. The reason for this requirement is that risks

can disturb the normal flow of activity if they trigger into an issue disrupting the defined work flow of the organization and mis-allocation of resources in resolv-ing the issue’s impact. Thus, the best approach in dealing with risk potentials is to correctly

identify, score, and priori-tize them within the scope of the organization’s envi-ronment in order to apply scarce resources to the highest potential return on investment for mitiga-tion activities.

Risk-based internal audits (RBIA) are strategically and operationally linked to the business goals and objectives. The RBIA framework maps the risks identified in the risk as-


By CA Wilson

Featured Staff Writer

“Risk

assessments at

the

organizational

level address

the business

unit areas that

could affect

the strategic

goals and

objectives…”


The PPPM Environment


An often misunderstood and more often misapplied concept in IT projects is the difference be-tween strategic and tactical pro-ject label and objectives. Many engagements for our services as a project whisperer (PW) involve dealing with the misalignment of a project by either a well-meaning but misinformed project sponsor that their project is stra-tegic when in fact it is tactical or operational in nature. Defining an IT project as strategic when it is not, or as tactical when it is actu-ally strate-gic can start the project down a path of difficulties ending in the junk-yard of early termi-nated or unfinished outcomes. This does not need to happen if the under-standing of the major difference between the strate-gic and tactical are organization-ally defined and implemented.

One recent engagement that we were interviewed for concerned this very concept or misalignment as was revealed during the inter-view process. The organization seeking our assistance described

the engagement as strategic in nature from both the labelling of the services desired, and the in-ternal structure (an enterprise project management office) to which the services were to be provided. During the interview itself the firm’s employees hold-ing the session began to describe the nature of the work effort for which they wanted to engage our expertise in the enterprise or strategic arena. However, all the projects and activities detailed as part of their current portfolio were of a tactical or operational focus. When it came to the inevi-table, ‘now do you have any questions for us’ part of the inter-action, they were almost in-

censed that our questions con-cerned this seeming misalign-ment of the work to the venue proposed. Finally, we had to ter-minate the interview and disen-gage from further consideration as these employees were obvi-

ously not understanding the na-ture of truly strategically focused projects.

What was the concept of strate-gic alignment this financial ser-vices firm was missing? It is the same that many organizations miss when defining what they consider strategic. When applied to IT project work in particular, many project managers (PM) and business analysts (BA) fall victim to this misunderstanding of how to define strategic versus tactical or operation foci. Understanding the difference is not difficult, but it would appear that it is not be-ing taught nor being enforced in today’s organizations.

Strategic IT projects are those that should ex-hibit three defining characteris-tics:

1. They are about pro-ducing de-liverables oriented towards the achieve-ment of organiza-tional vi-sion or mis-sion,

2. They are born in the halls of organiza-tional management or execu-tive perspectives, and

3. They should produce delivera-bles that expand the organiza-tion’s business or industry


“How are

strategic and

tactical

projects

identified so

they can

correctly be

classified for

both funding

and support?”

By Paul H. Lohnes

PMP, MBA, MCTS

Strategic vs. Tactical / Operational IT Projects


US Government IT Compliance Organizations


Within the myriad, confusing halls of the US Government (USG) there are many organizations that are tasked with the responsibility of providing IT governance and oversight to USG IT projects. This article will simply list and summarize these organizations as a way of illustrating that there is sufficient and sometime an overbur-dening of IT governance within the USG that could have and should have prevented many of the now infa-mous USG IT project missteps.

These USG organizations are:

The Defense Contract Audit Agency (DCAA)

The Federal Financial Institutions Examination Council

The Civilian Agencies Acquisition Council (CAAC)

The Defense Acquisition Regulation Council (DARC), and of course,

The General Accountability Office (GAO)

The Defense Contract Audit Agency (DCAA)

The Defense Contract Audit Agency (DCAA) provides audit and financial advisory services to Department of Defense (DoD) and other federal entities responsible for acquisition and contract administration. DCAA operates under the authority, direc-tion, and control of the Under Secre-tary of Defense (Comptroller)/Chief Financial Officer. Prior to 1965, each U.S. military branch had separate contract audit functions and regula-tions.

DCAA primarily conducts contract audits. Contract audits are independ-ent, professional compliance exami-nations of assertions (i.e., proposals,

claims, or submissions) made by de-fense contractors.

Types of audits DCAA conducts:

Pre-award Contract Audit Services

Post-award Contract Audit Services

Business System Audits

Negotiation Assistance

Federal Financial Institutions Exami-nation Council

Federal Financial Institutions Exami-nation Council (FFIEC) is a formal interagency body of the US govern-ment empowered to prescribe uni-form principles, standards, and re-port forms for the federal examina-tion of financial institutions and make recommendations to promote

uniformity in the supervision of fi-nancial institutions.

Board of Governors of the Federal Reserve System (FRB),

Federal Deposit Insurance Corpora-tion (FDIC),

National Credit Union Administra-tion (NCUA),

Office of the Comptroller of the Currency (OCC), and

Consumer Financial Protection Bureau (CFPB)

On October 12, 2005, the FFIEEC agencies issued a supplement (Authentication in an Internet Bank-ing Environment [2005 Guidance) to provide a risk management frame-work for financial institutions offer-ing Internet-based products and ser-vices to their customers. The purpose of this supplement is to ensure finan-cial institutions perform periodic risk assessments, look at new and evolv-ing threats to online accounts and adjust their controls (customer au-thentication, layered security) to these identified risks. It establishes minimum control expectations for certain online banking activities and identifies controls that are less effec-tive in the current environment. It also identifies certain specific mini-mum elements that should be part of an institution's customer awareness and education program.

The CAAC and DARC are councils charged with the update and mainte-nance of the Federal Acquisition Reg-ulations (FAR) that form the heart and soul of all USG acquisition prac-tices and policies. These two councils are the first line of FAR updates, modifications, and enhancements that include the oversight of their respective area’s IT project govern-ance as it applies to or is regulated by the application of FAR law and acquisition practice.

Finally, the GAO is probably the most well-known of USG IT governance organizations as it is charged with the fundamental oversight of almost all administrative and technological aspects of the absolutely gargantuan USG. The GAO and its many audits, engineers, and subject-matter-experts (SME) provide extensive au-diting activities across all the civilian agencies that comprise the USG. Their reports that are usually sent to the Congressional oversight com-mittees can be obtain on line or through the application of Freedom of Information Act (FOIA) requests.

By CA Wilson

PMP, RMP, CCEP

PH Lohnes, PMP

http://www.federalreserve.gov

http://www.fdic.gov

http://www.ncua.gov

http://www.occ.treas.gov

http://www.consumerfinance.gov/


Understanding Cognitive Biases in Decisions, P1


Decision making is touted and taught in most modern era busi-ness schools are a much needed skill and ability for members of management or senior leader-ship. The lessons taught are about defining the problem cor-rectly, discovering the require-ments a sound solution must pos-sess, collecting the right data to support the decision, analyzing the data for its reduction in un-certainty value, and then master-fully executing the chosen solu-tion. While all this sounds almost po-etic when delivered in a classroom setting at an ivy-encased campus on a crisp autumn afternoon, the real-ity is often far from this simplistic or deterministic ap-proach.

What is not dis-cussed unless the student is required to take organiza-tional behavior or psychology course work in completion of their academic pursuits is the im-pact that the hu-man factor has on all these nicely de-fined and detailed decision making steps. Have you ever wondered if decision making can be so accu-rately dissected, why do most people that invest in the financial markets lose their initial principle or make very little of a return? Or why so many very seemingly in-telligent people resourced against

a well-known and historically experienced activity such as de-signing and deploying an insur-ance web site can produce such a demonstrable failure?

Much of the causality of these examples and many, many others lie in how our minds (not brains) operate when confronted with the need to make decisions. The implication is about the human mind and its collection of what is called ‘cognitive biases’ (CB). CB are a part of being human, of belonging to the human race, or simply being cognizant of your existence. CB are those little parts of our lives that seem to frustrate

our good intentions or make matters worse when we know what is or should be done to rem-edy a situation. CB, in other words, are part of the human equation that seek to diminish our ability to make sound, effec-tive decisions or judgments.

Over the next few issues, this column will seek to describe the what, how, and why’s of our CB so that we can understand their makeup and attempt to effective-ly control how they impact our decision making abilities. First of all we need to understand just what is a CB?

By definition, a cognitive bias is the non-objective perception or inference of mental inputs that can lead to a distorted viewpoint of reality. Saying this in another way, CB are constructs of per-ceived reality that lead one to a state of irrationality. CB range from very mild or imperceptible

to those that make up what is called mental ill-ness. However, all CB are NOT bad. CB are the heart of what is called heuristics or thumb rules whereby a human mind can observe, analyze, and make valuable and effective deci-sions in what would appear to be supercomput-er level time frames without having all the nec-essary inputs or data that would otherwise be needed in a less urgent situation. Therefore, CB can both aid and de-

tract from sound, valuable deci-sion making.

The initial concept of CB was in-troduced by Amos Tversky and Daniel Kahnerman in 1972 grow-ing out of their interest in hu-


“...a cognitive

bias is the

non-objective

perception or

inference of

mental inputs

that can lead

to a distorted

viewpoint of

reality.”

By Paul H. Lohnes

PMP, MBA, MCTS


Preview of the AXELOS ITIL®


Continuing our inspection and investigation of the United King-dom Government’s (UKG) work in the area of project management ‘best practice’ definition and methodology development, the oldest and probably most well-known IT project management methodology framework is the AXELOS Information Technology Infrastructure Library (ITIL®) envi-ronment. While the name was probably not chosen for its aes-thetics, it does describe the con-cepts of use to a tee. It was ini-tially published between 1989 and 1995 by Her Majesty’s Sta-tionery Office (HMSO) on behalf of the Central Communications and Telecommunications Agency (CCTA).

As was mentioned in the last arti-cle reviewing the UKG’s work in this field, the UKG has turned over all their efforts to a private/public collaborative organization called AXELOS. Thus, this article is a summary review of the ITIL® methodologies as they apply to IT / ICT (information communica-

tion technology) project manage-ment.

In short, ITIL is a ‘widely adopted approach for IT Service Manage-

ment that provides a practical, no-nonsense framework for identi-fying, planning, delivering, and supporting IT services to the busi-ness.’ (from the ITIL official web site). It is a public framework that describes ‘best practice’ for the management of IT services.

The basic concept or principle of ITIL is that IT services must be aligned to the needs of the busi-ness and underpin the core busi-ness processes. Also, ITIL pro-vides guidance on how to use IT as a tool to facilitate business change, transformation and growth. ITIL provides five (5) core guides that map out their entire Service Lifecycle that is com-prised by five (5) stages:

1. Service Strategy,

2. Service Design,

3. Service Transition,

4. Service Operation, and

5. Continual Service Improve-ment

The current version, ITILv3, ex-pands on these stages to create a very detailed and complex pro-cess model. Figure 1 from the official ITILv3 documentation il-

lustrates how the ITILv3 Process Model defines key links, inputs, and outputs of the five service lifecycle stages.

The service lifecycle begins with a perceived change in business requirements due to any number of causes. These requirements are identified and approved in the Service Strategy stage via a Service Level Package (SLP) along with an associated set of business outcomes. From there, the SLP is passed to the Service Design stage where an appropriate solu-tion is produced via a Service Design Package (SDP) that con-tains all the necessary infor-mation and documentation need-ed to implement the new Service as it progresses through the re-maining service stages. In the Service Transition stage, the SDP is evaluated, tested, and validat-ed. The Service Knowledge Man-agement System (SKMS) is updat-ed and the service is then placed in service during the Service Op-eration stage. Finally, whenever it is appropriate, the Continual Ser-vice Improvement stage process-es identify opportunities for ad-justment of the service to com-pensation for any weaknesses or failures during any of the four other stages.

One of the very interesting un-derlying principles of the ITILv3 environment is the realization that customers do NOT buy products or services, they buy the satisfac-tion of particular needs that comes for the pur-chase of an organiza-tion’s products and ser-vices. For example, no one ever purchases a cook stove for the ex-press purpose of wanting a cook stove. They purchase the cook

stove for the satisfaction of pre-paring meals that meet the tastes


“The basic

concept or

principle of

ITIL® is that

IT services

must be

aligned to the

needs of the

business and

underpin the

core business

processes.”

By PPG Research Staff

http://www.itil-officialsite.com/home/home.aspx

http://www.itil-officialsite.com/home/home.aspx


Progress Checking Your IT Project


In any project management envi-ronment, methodology or frame-work there exists the require-ment of checking the progress of the project against some yard-stick or benchmark. In most bod-ies of knowledge this monitoring and checking is done in the phase or stage that is associated with the execution activities. The rea-son for a project to have begun execution before any monitoring or adjustments are attempted is that it is the execution of the pro-ject’s plan in accordance with its schedule and budget that pro-vides the performance data used in the variance analysis steps. But we are getting ahead of ourselves a bit, and so we need to under-stand why progress checking is so important.

While this question may sound ridiculous at first, we have to understand that there are IT project delivery methodologies that do not believe that a project executing under their principles is in need of much progress check-ing since for one or anoth-er reasons the project is either self-checking or the project sponsor’s repre-sentative is a member of the project team and able to judge for themselves how the project is pro-ceeding. However, in any case, the need for pro-gress reporting however slight or minimized by current practices will al-ways remain a require-ment for most organizations that utilize and expend precious re-sources in the completion of pro-jects.

Thus, we will discuss in particular how a general IT project can be progress checked without all the overhead of heavy-handed gov-ernance processes that in some industries particularly the public sector can place such a weight on the project resources just to satis-fy the governance requirements that it can actually skew a project by utilizing resources for the gov-ernance activities away from the planned project’s production of ‘fit-for-use’ deliverables. Govern-ance and/or progress checking should not be so over-burdening that it defeats the value of its findings.

So how can an IT project be checked for progress and still allow for the project to continue forward with minimal impact to its resource utilization? The pri-mary function of progress check-ing must be understood in order to answer this question in a sim-

ple and effective manner. First, progress checking for any human endeavour stems from the need for those that are funding or ac-

countable for a project’s exist-ence. If there was an unlimited amount of funds available or an unlimited amount of time given to the completion of a project’s work effort, very little progress checking would make sense. However, given the normal con-dition of unlimited demand for limited resources that constrain all projects, progress checks pro-vide the valuable information that decision makers need in order to determine if their re-sources are being effectively and optimally applied to defined business problems.

To start your progress check of an IT project there are a few parameters and characteristics that must first be determined in order to appropriately apply the right checks at the right times and places:

1. What are the defined deliver-ables of the project? (outcomes)

2. What are the de-fined quality metrics as determined by the project sponsors or customers?

3. What is applied outcome delivery method: traditional, iterative, agile, or cus-tom?

4. Who is the user of the progress checks and what is their pur-pose in these checks?

5. What if any are the chosen progress check methods and analysis?

These answer will pro-vide the initial platform from which the project

progress can be determined through an effective application


“To start your

progress check

of an IT

project there

are a few

parameters

and

characteristics

that must first

be

determined..”

By Paul H. Lohnes

PMP, MBA, MCTS


Improving Project Successes


Does it seem that your project team members just simply do not understand your vision of the project or its execution? Do your key stakeholders continue to question you as to the progress you and your team is making towards the pro-duction of ‘fit-for-use’ deliverables? Are you having to explain your deci-sions over and over to your pro-ject team or pro-ject sponsor? If so, you may be lacking what we call a ‘shared mental map’ or ‘shared mental model’ that out-lines your project in enough detail for your associ-ates and reports to understand and motivate from as you exe-cute your pro-ject’s plan.

As a unique and particularly effective tool that can be used in all project management venues, a shared mental map (SMM) can assist in solving the above ques-tions and issues that surround most activities involving a signifi-cant amount of planning for the future. Since a PM and his/her team spend about 99% of their time planning for the future, a SMM can help bridge the gap between what you, the PM, see as the appropriate future for your

project and what your key stake-holders including your project team envision. In some cases, project team members do not obtain even the smallest image of how the project should be rolled out or executed. This can be the seeds for many problems and wasted time or effort in having to continuously explain your actions

and decisions.

A useful SMM has several charac-teristics that make it an effective tool for combating confusion and determining what is next when moving into the executional phase of an IT or any type of pro-ject. However, given that IT pro-jects are ‘bit oriented’ type pro-jects – projects that produce soft-ware or process based outcomes that exist merely as bits in a com-puter, obtaining a common buy-in is very important and valuable.

A SMM can be the technique through which this can be easily and effectively accomplished. A SMM is basically a common men-tal map of how your project should be executed to comple-tion. It lays out the milestones, activities and processes required to bring the project to successful and constrained conclusion. The

SMM helps to derail team man-agement issues whereby the team members may not accept the manner in which you are exe-cuting the project not because they are at odds with you, but simply they do not grasp the landscape through which you are leading them towards the defined horizon which is the production of the project’s ‘fit-for-use’ deliv-erables acceptable to your pro-ject sponsors and customers.


“Are you

having to

explain your

decisions over

and over to

your project

team or

project

sponsor?”

By Paul H. Lohnes

PMP, MBA, MCTS

What is a “Shared Mental Map?”


Techniques Corner


Using last month’s article as our starting point, let us review the steps that we need to complete in order to use linear regression analysis to help us determine a more defendable value for our estimate of the time it will take to complete testing on our applica-tion given that we know the num-ber of Use Case Testing Points (UCTP) or variable (N) and the history of the actual testing times or variable (D) from previous pro-jects. Again let us point out that this is the main reason for col-lecting lesson learned data, pro-ject documentation, and project estimate values.

The steps from our previous arti-cle are:

1. Obtain dataset from our his-torical archives for UCTP and task durations

2. Using Excel or other spread-sheet, setup the data for N

and D

3. Create a scatter plot (X,Y) in-side Excel using the dataset in #2

4. Determine the trend line from the imposed dataset,

5. Discover the regression equa-tion from the dataset, and

6. Using the equation in #5, from the current task’s number of UCTP, estimate task duration.

Here is the dataset that our PM has discovered from her research from the Project Management Office’s project task duration ar-chives (the data shows the num-ber of UCP and archived actual time for testing in hours):

Creating a simple Excel spread-sheet, enter this dataset into the spreadsheet. If you would rather use the completed Excel file that is provided here, please feel free to do so. The spreadsheet has been created with multiple work-sheets showing the progress of the steps so that you can see how the spreadsheet is put together at each step of the process.

In your Excel spreadsheet (worksheet1 of the provided Ex-cel file), the data is entered simp-ly as a two column set of data. Please do not get lost in the addi-


“Make your

spreadsheet as

basic or

advanced as

your Excel

skills allow….

Using the

dataset it is

now time to

create a

simple scatter

plot chart…”

By Paul H. Lohnes

PMP, MBA, MCTS

Improving Decision Making with Linear Regression Analysis II

Use Case

Testing

Points

(N)

Testing

Duration

In hours

(D)

6 128.00

8 146.00

9 180.00

3 64.00

4 92.00

10 181.00

15 365.00

19 351.00

6 122.00

10 213.00

Figure 1: Creating a Scatter Plot (XY) from Dataset

EXCEL

Spreadsheet

http://projectgazette.com/files/TargetedV_Fig1.jpg

http://projectgazette.com/files/LRA_Example_PPG_Nov2013.xslx



After working on a large scale complex program with multiple projects, I found as a risk manag-er, one of the areas of concern was risks being managed at the project level that were not pro-ject level risks. If a risk is man-aged at the wrong level, the Pro-ject Manager (PM) finds they are unable to mitigate that risk as they are not the ones with the ability to affect change to that risk. If a risk is at the program level, they will need resources with program level responsibili-ties to effectively make decisions at that level. This even applies for risks that need to be deesca-lated from the program level to the project level.

Risk Management escalation is the concept whereby a risk or issue is identified as needing to be reassigned from one entity to another or from one level to an-other. In order to effectively esca-late risks, a formal escalation pol-icy should be written to incorpo-rate any specific requirements within that organization to en-sure timely resolution of deci-sions within each organization.

The purpose of the risk escalation process is to provide a framework and reference guide for the Pro-gram Management Office (PMO) user community or PM to support their management of risk escala-tion by elevating both score and ownership of risks items through each stage of the project/program structure. The concept of risk management escalation is to provide for changes whereby additional resources or visibility is needed to improve the manage-

ment of an existing risk or issue. The escalation process is not meant to deal with initial risk vetting or scoring concerns.

Your process should provide the tasks and activities associated with identified risk escalation.

Several assumptions should be considered:

Projects under each program maintain their own risk registry and issues log and report to the other PM within the respective program on a periodic basis.

The Program Manager in con-cert with his/her PM will rec-ommend risks that need to be escalated to the program level or managed at project level

The risk escalation process must be defined, approved, and made part of the project / program / portfolio management (PPPM) environment as risks or issues that are incorrectly categorized can fester or worse be ignored until it is too late to apply any meaningful mitigation action to their prevention or assessment valuation. Many projects that have risks or issues for which they cannot properly mitigate due to this incor-rect place-ment simply ignore them un-til the project ends (lucky coinci-dence) or until the risk’s trig-ger invig-orate it

into life with all its negative im-pact, costs, and frustrations.

For example, during the IRS tax exempt scandal, it was deter-mined that there were several risks and issues that were never escalated to senior leadership for resolution and so became the focus of the scandal after the actions of the internal IRS em-ployees proved that the concepts that supported the increased scrutiny did indeed originate at the higher IRS management lev-els. Since the risks and issues were never moved up the chain using a properly designed risk escalation process, the risks be-came issues, and the issues be-came the source of the very pub-lic and damaging scandal for the Service. Remember, non-escalated risks and issues can hurt when ignored and left to fester. Had a properly designed, implemented, and managed risk escalation process been in place at the Service, the scandal may never have occurred due to the fact that the additional scrutiny may have been handled quietly and legally within the Service without the need for Congres-sional oversight.

Risk Basics Targeted Series

What is a Risk Escalation Plan?

“Risk

Management

escalation is

the concept

whereby a risk

or issue

identified as

needing to be

reassigned

from one

entity to

another or

from one

level to

another.”

By CA Wilson

PMP, RMP, CCEP



Last month in the PPG, we dis-cussed “What is Project Risk” and “Not all Uncertainty is Project Risk.” We got a lot of conversa-tion on these topics and it was good to know people are con-cerned about how to really un-derstand and deal with project risks. From the conversions that were generated, the most concern was about how to identify risk causes and triggers in their IT projects. We have seen project after project team attempt to iden-tify anything in the future as a risk regardless of its true na-ture or content. It is so im-portant to be able to both identify and analyse the right project risks as risks, risk causes as causes and triggers as triggers. Often project team members identify risk causes and triggers as risk potentials and then spend wasted time trying to miti-gate the wrong risk compo-nent.

Risks are uncertain future events that if triggered into reality will cause a negative impact to the production of the projects ‘fit-for-use’ deliv-erables.

Risk causes are events or con-ditions that make the risk a negative impact to the deliv-erables, but they are not the risks themselves.

Risk triggers are the future events that turn a risk potential into a reality or an issue.

An example may be necessary to help solidify these different risk components. Let us consider a

project that must generate infor-mation that is required by recent government legislation. In other words, your government has mandated that organizations in your industry do their accounting for widgets differently in order to ensure that domestic widget pro-duction is not shipped off shore thereby reducing jobs in your country. The new widget ac-counting information must be

reported on your firm’s next an-nual tax reporting document that is due to be filed with your gov-ernment’s tax authority in just over 6 months. This is quite and recently possible; we will let you figure out the details if you are interested.

The new widget accounting infor-mation will require some very new measuring, monitoring, and reporting activities that your or-ganization has never attempted before this new mandate. So, let us begin with some simple identi-fications so that we can learn how to accomplish these classifi-cations.

First, and foremost, before any risk, risk causes, or risk triggers

can be identified, the project deliverable along with its ‘fit-for-use’ quality metrics must be identified and understood. In our example, the delivera-ble is not the process, nor the tax form, it is the information that will provide the correct details that your govern-ment’s tax authority requires from your firm in about 6 months. If you did not get this the first time, do not be dis-couraged. Most people start off by identifying the wrong deliverables and therefore identify the wrong risks, caus-es, and triggers.

Consider the following con-cepts:

The process is not the deliv-erable since the process can be delivered but incorrectly utilized by the end users thereby generating bad infor-mation,

The tax form is not the de-liverable since it is only the physical reporting artifact on to which the widget produc-

tion information is going to be placed,

The metrics, monitoring points, or analysis are not the delivera-bles since these are only the manner in which the raw data is collected and turned into the


Risk Concepts Targeted Series

By PH Lohnes

MBA, PMP, MCTS

“...before any

risk, risk

causes or risk

triggers can be

identified, the

project

deliverable

along with its

‘fit-for-use’

quality

metrics must

be identified

and

understood…”

Identifying Risk Causes & Risk Triggers in IT Projects



defined “fit-for-use” deliverables without which the joy of newness is dampened, and the excitement of project management that we have experience at some time in our ca-reers turns into the daily schlep along a dull and dusty trail from pro-ject initialization to a lackluster pro-ject completion. Business cases tell us why the project is important, why we are needed, why our actions to-wards successful completion have meaning.

The business case starts the project’s lifecycle, defines the value the pro-ject’s deliverables can provide to the organization, illustrate the im-portance of proper project manage-ment and business analysis, and be-come the birth certificate of the pro-

(Continued from page 6) ject’s need to exist. The business case tells the organization that the project is significant, has relevance, or demands their attention. It gives rise to why stakeholders should in-vest their time and effort in partici-pating in the growth and develop-ment of the project when asked to provide input or resources that will increase the chances for the project’s progress towards maturity and ulti-mate completion of its valuable mis-sion of producing the defined out-comes for use by the its customers or end users.

Business cases should be more than a checklist box on your organization-al project’s lifecycle governance form. The business case should be well-crafted, designed, and complet-ed as any other project artifact of significance. The mere fact that busi-

ness cases exist before the project is actually born should not diminish its importance or stature. An organiza-tion that uses the PPPM model to improve its value to its stakeholders should if not already a part of its rep-ertoire reinvigorate its business cases development and utilization activi-ties. The results on its project success rates might be surprising, so…

Return the joy of project manage-ment to your professional environ-ment – ensure that project business cases are given the due attention and care they demand and require. Re-member the excitement you felt the first time you were assigned the role of project manager or lead business analyst on a project – know why you are doing what you do: work the business case.

Editorial (cont.)



A prototype, or a

A business process

Samples of sub-deliverables could be:

Software requirements,

Technical or security standards,

Database schema or design,

Technical procedures,

Assessment report, or

User interface module or screen.

Some guiding principles for deliv-erables under the DCPM concept:

1. All projects have one main deliverable, but are some-times combined into programs with several deliverables,

2. All work (tasks) produce a deliverable or sub-deliverable,

3. Deliverables define the pro-ject: no deliverables, no pro-ject,

4. Deliverable quality is defined by the customer or sponsor as “fit-for-use,”

5. Completion of project is ac-ceptance and sign off by the customer/project sponsor for the production of “fit-for-use” deliverables.

Many risks listed in the Risk Reg-ister (RR) are causes of the risk itself and not risks themselves. Remember, risks are tied to our project deliverables. Under-standing the causes of project risks and their associated triggers (events that turn a risk into an issue) will increase the value of information your RR will provide to the project team.

Step Two.

Understand inherent roadblocks to most IT projects and ensure the management of these imped-iments under the PM umbrella

(Continued from page 7) and NOT under the risk environ-ment as risks. IT projects have common and related activities that should be managed as part of the project being an IT project – activities that stem from the project producing informational artifacts. These activities even though they are in the future do not constitute risk, but activities that an experienced and skilled IT PM understands are part of their project environment and they should be managed as such, not lumped into the RR to hopefully provide some coverage if the PM is not able to manage his/her team to the achievement of the activities within the project con-straints.

Some examples we have seen called risk, but are actually typical IP project activities are:

1. Vague requirements due to:

Limited knowledge of project deliverables at project initializa-tion,

Incomplete or unfocused pro-ject business case development by sponsor or customers,

Misunderstanding of the busi-ness problem or underlying

dissatisfaction of the status quo by project sponsors and/or cus-tomers

An experience PM will under-stand that vague requirements are normal for an IT project and act or manage accordingly with-out the need to call them risks. He/she will understand how to PLAN, EXECUTE, and MONITOR their completion as project ac-tions that lead to the production of “fit-for-use” deliverables, not uncertain future events – the definition of project risk. Label-ling vague requirements a project risk is making the mistake of attempting to manage your pro-ject through the risk register. Skilled IT PM know that vague requirements are signatures of any IT project, but then also know the solutions for their completion such as:

how to define them,

how to plan their implementa-tion,

how to execute their achieve-ment, and

how to sequence these activi-ties into the actions needed to produce the contracted deliver-


“Many risks

listed in the

Risk Register

(RR) are

causes of the

risk itself and

not risks

themselves.”

The Risk Line: Risk in the IT Environment (cont)



ables all without using the RR as a crutch.

Risks are those potentials that negatively impact a project if they become reality – they are not normal project activities plopped into the RR in order to provide coverage for possible future pro-ject failure. If the creation, defini-tion, description, and approval of project requirements are consid-ered risks then the PM must also include themselves and their BA

as risks as well since these should be skills already within the toolkit of any IT PM or BA. One cannot have it both ways. See this issue’s Project Whisperer column for when it is not in your best inter-ests to take a project engage-ment where one of the major reasons involves the inability of the customer or sponsor to clear-ly define their business problem.

2. Request for additional require-ments or the dread ‘scope creep’.

Unanticipated request for re-quirement changes.

Customer or sponsor deciding they want more than originally contracted.

To minimize scope creep, ensure the customer or sponsor has

(Continued from page 40) signed off on the project charter or the Statement of Work (SOW) to determine the project bounda-ries well defined. Any require-ments identified as non-contracted work will need to be discussed as to their applicability to the current project as the work defined by these additional, out of scope requirements, may in-crease the potential of project failure due to scope creep. A request for additional require-ments is not a risk; it is a normal part of project management that needs to be managed under the

PM um-brella. A PM worth their weight in gold under-stands that the custom-er re-questing addi-tional work is always a

possibility, but managing this under contracted project con-straints is what the PM is sup-posed to do. While many say “never say no to the customer,” a smart PM knows when to sug-gest, “not no, but not now.”

3. Project duration estimates are not initially accurate. This actually is very common due to the fact that most projects are defined by those not ac-complishing the work. Project durations are chosen for a variety of reasons, but usually not for their accuracy or preci-sion as to the actual work effort that will be needed or the acquisition and assign-ment of needed resources. These durations or deadlines

are defined by politics, busi-ness cycles, funding con-straints or simply on the whim of the business sponsor with-out subject matter experts or historical data being applied to the project time frames.

Again, an experienced PM will ensure adequate duration buffer-ing without overly expansive with respect to the project schedule or deadline. We know this is against everything you learned from the traditional bodies of knowledge teachings, but if this is a known problem then PM need to handle this as part of their management expertise and not rely on listing them along with other project management aspects in the risk register as a way of “covering one’s assets.” PM need to work with the business case develop-ers at the start of a project’s ini-tialization process to prevent such imprecise or unworkable project constraints making to the project’s charter or SOW which then become unfortunately part of the project’s contract thus setting the project up for early failure.

In this article we have covered a significant number and breadth of topics surrounding the correct perspective of project risk man-agement. A PM that has spent any amount of time “beating their head” against the proverbial brick wall of project failure comes to the conclusion that doing one more project in the same way, using the same tools, thinking the same mindset, but this time ex-pecting success is, well, you know… Use some or all of these suggestions on your next project, and you will be surprised how more easily you can deal with the twin “horn of the dilemma:” suc-cess and uncertainty without call-ing everything in a project – a risk.

“Project

duration

estimates are

not initially

accurate. …

most projects

are defined by

those not

accomplishing

the work.”

The Risk Line: Risk in the IT Environment (cont)



will get to using the project schedule to support what-if simulations.]

Now that we have seen how project schedules have become due to the implementation of powerful software application platform features, should the project schedule be placed under control or should it be allowed to be tweaked without going through the project’s defined change control pro-cess? If you want a project schedule to support the execution of a project, support the decision making of the

PM, BA, and oth-er key project team members, then the project schedule must be placed under control to pre-vent its dilution or disintegration into mere docu-mentation. This means that changes to the schedule must be analyzed, as-sessed, and ap-proved before added to the schedule proper. For those that are used to tweaking the schedule dai-

ly, please consider that if you are not experiencing schedule utilization and application towards the successful completion of a project, you may want to consider altering your meth-ods of schedule creation and use.

So, to recap, a schedule baseline is one that exhibits both an approved status as well as being placed under the auspices of the project’s defined change control process. Both charac-teristics are necessary for your project schedule to be truly classified as a schedule baseline and not just a run-ning, alterable form of project docu-mentation.

Next issue we will discuss the three vectors of a sound and useful sched-ule: the tasks, durations, and re-sources. See you then.

while requiring only marginal approv-al for the details of the summary tasks as they become more visible and defi-nite. This does not mean that the schedule must be re-approved every day or week. The PM, project sponsor, and key stakeholders can come to an agreement on the appropriate fre-quency of re-submittal and content updates for the schedule.

While we now understand what is meant by the first characteristic of being approved, many of the projects onto which we are called to provide project whisperer consulting, we find that the schedule has never been offi-cially approved, and worse it is in a state of almost constant flux with dai-ly and sometimes even hourly chang-es occurring to the primary tasks, in-terdependencies, durations, and re-source assignments. We are not im-plying that time and attendance data from the task resources should not be included into the schedule since this is one of the more advanced features of enterprise project management soft-ware solutions; we are saying that making the schedule match what has occurred as if it was planned to occur (we call this schedule history realign-ment) to make up-line managers hap-py or make reports turn out more supportive of congratulations is NOT project success conducive.

The project schedule baseline is a component of project planning – not documentation. It should reflect what was planned for project progress not altered to make it match what has actually happened. The whole con-cept of a baseline or benchmark is that the yardstick is not altered during the execution phase of a project un-less it has been subjected to the pro-ject’s defined change control process. WOW! This statement will cause some heart palpitations for many readers; however, read on, we prom-ise we will make your heart slow down in a bit.

Does this mean that the schedule is approved once and never changed?

(Continued from page 8) NO! It simply means that the schedule baseline is an approved schedule for which the project’s key stakeholders have agreed at least in principle to its effectiveness and efficacy towards producing the deliverables that will ultimately provide a solution to the original project’s dissatisfaction with the status quo – the project’s business case or statement of work.

As the project schedule through the process of rolling-wave planning, pro-gressive elaboration, and step-wise

refinement (all of which have been discussed in previous PPG articles on scheduling) is ‘fleshed’ out with re-spect to FUTURE events, tasks, and assignments, it is of course updated for the purpose of providing execu-tional value to the PM and project team. However, given today’s power-ful project software solutions, the project schedule is becoming the point where ALL project data is ar-chived and this leads to the tendency to keep it both as a chronicle of past performance (the alteration of planned to what happened as if it was planned) and a holder of all project data further placing on it the need to be both historically accurate to actu-als as well as how those actuals now altered to match reality will impact the future [Please – stop shouting – I

The Schedule Dispatch (cont.)



to be “just like their bigger cousin” they purchased and tried to imple-ment the same toolset.

First, when completing an As-Is re-view to establish a baseline of solu-tion implementation and utilization, it was discovered that the only fea-ture of this impressively capable soft-ware solution implemented by this organization was the time and attendance (T&A) capability. While the solution was capable of sup-porting a complete top-down PPPM environment from ideation to desk-top scheduling, this organization had decided to only implement the very simple automation of the employee time sheets. The entire feature set of the PPM tool’s T&A feature set was not even implemented – just a policy that every day each employee had to put their 8 hours into one of the task categories offered to them by their project management team. The task categories did not even match the actual work since the cate-gories were not drawn from the use of the PPM tool to manage their projects, but simply find places to put each worker’s 8 hours. The discipline for this was quite powerfully moti-vating, but the discipline to do it correctly was totally lacking.

At a result of this limited disci-plinary approach, those that were tasked with making the T&A reports at the end of each reporting period had to spend a significant amount of time mak-ing the reports match what was known by anecdotal under-standing. The value of even the lowest utilization of this power-ful and costly PPM tool was diluted with extra manual and unnecessary labor by very capa-ble personnel that could have applied this work effort to more revenue generating value. The outcome was almost useless reports that varied widely from period to period – not even coming close to known actuals.

(Continued from page 9) Second, when confronted with these facts, one of the organization’s prin-ciple SLT members, the Chief Finan-cial Officer (CFO), did not want to employ the suggested level of disci-pline necessary to remedy the poor reporting situation. The CFO’s re-sponse was that the application of data discipline, as it was presented to the SLT, was unnecessary since soon-er or later the users of these non-informative reports would see their limited application, and would set up to provide the required discipline to correct the problem.

Well, as you can guess, nothing changed, and as far as can be deter-mined, nothing has changed in the 18 months or so since the sugges-tions for remediation were delivered. This organization will most likely con-tinue to “do things as we have al-ways done them” in the use of this PPM toolset until a new SLT is put in place and the actions of the previous team will then be scrutinized as they

usually are when such changes occur. Hopefully, this lack of discipline will become a point of change for this organization so that the power and feature-rich set of solution capabili-ties that have been so successfully implemented at other similar organi-zations can be allowed to have their impact.

So why is discipline such an issue with many SLT or management teams? Our research has indicated that it is rooted in one of three possi-ble causes:

1. Need of the SLT to be seen as benevolent,

2. Fear of legal reprisals especially in union-oriented environments, or

3. Desire to be seen as politically correct.

These causes for the lack of discipline are all part of the “modern organiza-tional ethics” that appears to affecting most organizations. Man-agement in many organizations does not feel it has the right to ask their workers to work or accomplish activi-ties that will improve the organiza-tion’s business persona or standing. Altering the As-Is is considered here-sy in many business realms. Let us go along to get along. In some cases, the SLT will make a big splash about a new business policy or process, but then fail to follow up thereby giving their tacit approval for their direct reports to ignore it once a suitable amount of time has elapsed.

Discipline is required and demanded if the organization desires to benefit from their implementation of a PPPM environment. To understand the value of a PPPM solution, simply look to those business entities that are growing, shaping their industries, and making progress. Most if not all have a well-developed sense of stra-tegic alignment between their vision or mission and the activities such a projects, programs, and portfolios that will help to achieve this horizon. Very few organizations just luck into success – it is a matter of hard work, and oh yes, discipline.

The PPPM Roadmap (cont.) Porject Management Discipline



The BA Forum (cont.) Assigning the BA First!

not even involved a professional BA. The entire purpose of a busi-ness case or pre-authorization analysis is to determine if the project should even be instantiat-ed or if so, should it be funded during the current cycle. The lack of closing the loop between the business case or project instantia-tion and the assignment of a pro-ject’s PM can provide the rich medium for the birth and growth of risks, issues, and other negativ-ities that can attack a project be-fore it is even given the chance to reach a level of self-sufficient maturity. An early assigned BA can cham-pion the busi-ness case or pre-authorized project mass towards either its subsequent funding event or show why the business case lacks the business value to be consid-ered for the additional ap-plication of organizational resources. Funding and pushing pro-jects that will not or do not improve an organization’s future busi-ness acumen is just as wasteful as not approving those that are. In either case the opportunity costs could be dramatic with respect to the organization’s future.

The assignment of the BA to a project or pre-mass project has two benefits to the project’s fu-ture success:

(Continued from page 10) 1. The BA as mentioned should pro-vide the business value under-standing, and

2. The BA has the organizational business understanding that can accurately assess the project’s alignment with the organizational mission or vision.

The professional BA should be more acutely tied into the business of the organization than most PM given the focus of the PM towards the comple-tion of the project in an optimized manner. The PM is distracted from the higher business value their pro-ject may provide and oriented to-wards obtaining the best resources

necessary to complete the produc-tion of the unique deliverables de-fined by and hopefully acceptable to the project sponsors or customers. In this role, the BA is the stakeholder primary liaison to the project even in the pre-charter or authorization phase. Upon the authorization or award of the project, the BA be-

comes the founding member of the project whereupon his/her knowledge can be pollenated into the PM and other team members as they are acquired.

While this may not be the norm to-day, the assignment and support of the BA in the early stages of a pro-ject’s life can bring solid and business empowering value to any organiza-tion’s use of the PPPM model for project completion. Remember, the entire concept of using projects is the production of unique delivera-bles through limited time lived activi-ties that increase an organization’s business prestige, shareholder value,

or mission achievement. Operations are not activated towards this horizon – they are the results of successful pro-jects delivering on their business promise of ex-tending the or-ganization into avenues and paths not consid-ered or demand-ed in previous business cycles. Organizations do not grow by op-erations; they grow by instanti-ating projects that lead to valu-able new pro-cesses, opera-tions, and prod-ucts not hitherto

developed. The use of a professional BA positioned at the right time and with right knowledge and skills can provide the burgeoning project with successful mixture of business value and constraints needed to recipe its future completion of customer needs.


Powerful Techniques for Influence and Leadership available on Amazon Also in Print http://smarturl.it/silentinfPrint Find Michael’s other publications on: http://www.amazon.com/Michael-Nir/e/B00B0S45W0


ed into personal zones. These zones are maintained zealously. Make sure you are not crossing the lines. Alter-natively, it can also serve as an oppor-tunity to move away from negotiation stalemates and conflict situations by

reorganizing the physical setting as the meeting progresses and no deci-sion is reached. King Arthur knew about personal space and seating hierarchies and opted for a round table. Sometimes, better decisions are reached away from the formal meeting table of long rectangle heavy mahogany. A low circular table in the lobby or sitting in a corner can yield better results. Observe your personal office space; can you imagine how guests and col-leagues feel there? Experiment with changing the physical surrounding. Change seating arrangements often to increase the opportunities for silently influencing.

—————————————— Want to learn more about Silent Influ-encing? Silent Influencing - Employing

everyone is doing what s/he thinks should be done rather than stating what s/he would like to achieve. Sometimes, to overcome an impasse, I might carry out a shrewd move and

offer the resisting colleague an object such as a pen, a document, a paper during the meeting to influence his/her chosen closed position physically. This can result in him/her opening his/her folded hands, or shifting for-ward in his/her chair. Also, my leaning forward toward him/her will create some physical response in him/her. The change in the outward behavior changes the inner attitudes, just as surface behaviors generally are a re-flection of inner feelings. Influencing Through Surrounding Space Notice how you use the space around you such as an object on which you place your hands as though you claimed ownership for it. Pay attention where your hands wan-der. A meeting table is virtually divid-


Practically Proven

Michael has been providing operational, organizational and management con-sulting and training for over 14 years. He is a certified project management profes-sional and Gestalt process facilitator, offering training, consulting, and solutions development in project and product man-agement, process improvement, leader-ship, and team building programs

Michael’s professional background in-cludes a significant amount of work in the telecoms, hi-tech, software development, R&D environments and petrochemical & infrastructure business.

Michael travels extensively to Europe and East Asia, conducting training and con-sulting. He understands people, organiza-tions and cultures and has a high degree of comfort leading cross-functional and cross-cultural training. Whether he focus-es on the "soft side" or on project busi-ness skills, or a combination of both, he is effective facilitating learning on myriad topics, including negotiations, conflict management, and influence without au-thority, leadership, body language, and presentation.

He holds two engineering degrees from the prestigious Technion Institute of Tech-nology: a Bachelor of civil engineering and a Masters of Industrial engineering.

http://smarturl.it/silentinfluence


http://smarturl.it/silentinfPrint

http://smarturl.it/silentinfPrint

http://www.amazon.com/Michael-Nir/e/B00B0S45W0

http://www.amazon.com/Michael-Nir/e/B00B0S45W0




with much less.” Project spon-sors generally accept that a viable strategy is to cancel projects in order to free-up resources for other more needed projects. This strategy is met with increased resistance in the current economic climate because resources have been cut more dramatically and there are fewer projects that can be cancelled with-out detriment to an organi-zation’s overall business strategy. As a result last ditch efforts seem to be par for the course.

The imperative is for pro-

(Continued from page 12) ject managers to determine from their sponsors, whether their project is a last ditch effort or not. If so they must focus on completing the project while mitigating the risks involved when Resources are Inadequate. However, if they find that the project

is not critical to the survival of the organization, they may help their sponsors by making a case for the cancellation of their project. The redistribution of the cancelled pro-ject’s resources can then help critical projects succeed. Of course, sug-gesting that a project you are manag-ing be cancelled may put you on the list of potential lay-offs, which is the conundrum.

Muto Performance Corp. provides project obstacle mitigation consulting services. Our streamlined, specific, and resolution focused methodology thoroughly explores all aspects of the obstacle at play. For more infor-mation about us go to http://www.mutoperformancecorp.com/

MuTo Performance Corp - 2013 Survey Forum (cont)

ject turtles are the slowest, most methodical perfectionist bunch. Nothing leaves their desks until it is perfect! Start to think of your project like the jungle it is, and you will make more headway to the ever-changing land of milk and honey.

Fear #3: But What if I Fail? Here is a quick homework activity for you: Ask the next 3 people who pass you about their day. Listen for what they begin with. (That’s it.) Studies illustrates that more people begin to verbalize their experiences with negatives than with positives. We have to make it a point to select positive thoughts, behaviors and actions to improve performance in pro-ject management. When asking several PM about their projects, I changed my questioning tech-nique to:

(Continued from page 13) “What would you do with this pro-ject if you could not fail?”

That question poses a completely different response. It presses you to search the innovation lab in your mind to uncover new thinking, new solutions, and alternative methods. Realize that most project manage-ment in organization is steeped in tradition. Leave it there. Work from the notion of succeeding at all costs. Task your team to come up with ide-as to implement if they were guaran-teed not to fail. You will be amazed at the level of innovation right under your nose.

Fear, if used properly, can be the ultimate motivation. It helps us prior-itize, focus, regroup and come back stronger than ever. I conducted a virtual keynote for a group of high school students in Georgia last month. Our topic: Overcoming Fear. I had them create their personal acro-nyms for fear. One of the most sub-

stantial ones was “Future Environ-ment At Risk”. My notion of negative responses is true, even with our chil-dren! I urged them to change their thinking and focus on positive actions resulting from fear. By the end of the 45 minutes, all 20 participants agreed that they would implement a new acronym for fear: Face Every-thing And Recover.

Can you do the same?

————————————

Chris Daniel, PMP, America’s voice of new leadership helps new leaders create award-winning organizational results and foster phenomenal strat-egy, processes and people. His new book Consult in Jeans brings real client stories to life, while engaging readers to consult themselves on personal strategies to win at man-agement and leadership! He travels the country speaking, training new leaders and consulting in jeans. Find out more at onechrisdaniel.com.

The “Consultant in Jeans®” (cont)

http://www.mutoperformancecorp.com/

http://www.mutoperformancecorp.com/

http://onechrisdaniel.com



Given that most organizations that utilize projects for their im-provement and growth (which should be most all healthy busi-ness organizations) are organized into a hierarchical structure of both management and labor. Remember Adam Smith, Freder-ick Taylor, Alfred Sloan, and Peter Drucker as they all began the focus on professional or scientific management that divided the work effort between the workers (labor) and supervisors (management) while before the 20th century most of the responsibil-ity of work fell to the actual work-ers. With this his-torical perspec-tive in our back pockets, what does temporary teams have to do with poor project performance?

Quite simply teams perform better than a close association of strangers. Real-ly? Is it that sim-ple? YES! There has been study after study, research efforts, and investigations of disasters such as the one alluded to in the opening piece on this issue’s editorial page (see the Page 4 Mini). For the skeptics, let us list some of the studies that have brought forth the advantages of teams versus groups – my terminology for the difference between pro-ject permanent and temporary work effort associations. I know that currently PM use the term ‘team;’ however, I use the word ‘team’ in more the consistent

(Continued from page 14) form from current day sports, athletics, military, and law en-forcement associations. One would not expect a police special weapons and tactics (SWAT) club to be as effective as a long-standing, heavily dependent, and balanced SWAT team nor would the special operations of today’s standing military organizations function well with a SpecOp co-operative.

Teams generate their effective-ness from the bonding, trusting, and familiarization of the mem-bers amongst each other. How

would a professional sports fran-chise function if its members were consistently being moved around between the league’s organizations every game or con-test? However, this is precisely the situation for most project ‘teams’ at both public and private organizations. The value of more permanent teams cannot be more appropriately suggested than by the investigation of the 1949 Mann Gulch fire in Montana where 13 trained and experi-enced smoke jumpers lost their

lives when they became confused as to the actions and commands of their temporary and somewhat eccentric leader, Wagner (Wag) Dodge. Wag started out the event in command of a group of trained, but temporarily assigned jumpers that were drawn from a rotating list of fire fighters. Since Wag did not intently know the men in his crew that fateful day, and they had not worked with Dodge enough to gain both a trust and understanding of his management style when the fire turned deadly and Dodge started issuing orders that did not make

sense, his crew be-came confused and disoriented. The re-sult was that 13 of the 15 jumpers did not survive.

In the book, “Young Men and Fire,” by Norman McClean, the details of the disaster point to many causes and reasons for the failed fight, but one in par-ticular surfaces when after the fire had become vicious and threatening, Dodge completely changed his demeanor and

attitudes towards the situation. However, the crew could not put his abrupt change in professional demeanor from one of calm, as-sertive, and confidence to one of urgency, excitement, and flight. Dodge’s lack of bonding and trust with his team while they respect-ed his persona of being an excel-lent crew and fire fighter leader, they could put his new “danger approaching” orders into context. He was telling them to drop their equipment and run! Commands


“Quite simply

teams perform

better than a

close

association of

strangers.”

“There has

been study

after study,

research effort

and

investigations

of disasters…”

Why Temporary IT Project Teams Fail the Project?

In My Opinion (cont.)


hierarchical layout given our new forms of communications (a topic for next month), the smaller cadre of advantages that temporary teams provide will give way to the significant benefits of more perma-nent teams as outlined previously.

If our professions are to grow and improve, we must always be willing to challenge current perspectives and ideas. Growth is not always easy nor acceptable to those that seem to hold the status quo near and dear. We that do see a brighter future for our disciplines need to confront and stand in the breach to get those of the static to see that there are better and more produc-tive solutions available to improve the success rates of projects. Do not be timid. Show these articles to those that might not agree and get them to at least begin discussing their current views and listen to their support of why the status quo should remain. In this manner, they will usually provide the seeds of

their own limited view of the profession. Above all, do your own homework – research, study, uncover the basis for why things are being done the way they are at your organization. Change is both neces-sary and demanded by the mere passage of time else we atrophy and begin irrelevant.

Next month we discuss more status quo project management concepts that need to be challenged and shown the light of day. See you in December.

PH Lohnes, PMP, Editor-In-Chief

The Project Post-Gazette

Alexandria, VA USA


that were completely contrary to their training, and without any team bond-ing context, lacked the motivation of force and obedience. Some of the fire fighters’ remains were later recovered still clinging to their heavy and awk-ward equipment.

We in the PM&BA disciplines need to be aware that our disciplines are be-coming part of dramatic and public project failures which can be traced back to simply the inefficiencies of temporary teams. Temporary teams lack the cohesiveness and familiarity that permanent teams form over months and years of interworking and collaboration. In my opinion, the mod-ern day project team especially for the IT project should be analogized as a train that has a PM at the head (like the engine) subsequent supporting elements, but then a long stream of deliverables that can be completed along the way and then having achieved “fit-for-use” status dropped off at the next transpor-tation center for deliv-ery to the customer while additional deliver-ables for other custom-ers are added or linked into the train’s more permanent structure. In this manner, the now permanent IT project team can form bonds, build trust, and develop efficient collaboration links that will improve the success profiles of projects – not work against them.

The makeup of more permanent pro-ject teams should be given some thought and I suggest that the perma-nent nature of an organization’s pro-ject team need not include every skill or ability that MIGHT be needed, but only the core members such as a PM, BA, risk manager (RM), scheduler,

(Continued from page 47) financial analyst, lead developer, lead tester, etc. For most IT projects these core roles and skills would be the nu-cleus of the team where after which others could be recruited as needed or required. The core members would have a solid working and professional relationship foundation upon which the other team members could be placed and deployed. While I do not have any empirical data to prove this assertion; however, it would stand to make common sense that a more co-hesive and familiar team core will be more productive and organized allow-ing projects to gain the advantage from the start of an engagement in-stead of beginning behind the planned versus earned value curve, so to speak.

Do temporary teams have ad-vantages? They do. They are lighter weight from the stand point of cur-rent HR and employment demands of governments and sovereignties. They can be staffed with temporary mem-bers with necessary skills and then

released when their skills are no long-er needed. They fit well into more hierarchically structured organizations where project team resources must be “borrowed or begged” from the functional divisions. As the modern organization especially those that see the value of the project / program / portfolio management (PPPM) model morphs into a more efficient structure not based on the somewhat outdated

Why Temporary IT Project Teams Fail the Project?

In My Opinion (cont.)



The major assumptions of the CPM given by the method creator, DuPont, were:

1. Task estimates are normally dis-tributed,

2. There is no merger bias or path convergence, and

3. The project has unlimited re-sources available to it.

The last major assumption of the CPM technique and probably its most alarming is that all resources assigned to a project are applied at a 100% availability rate. To clarify, CPM assumes that project are NOT re-source limited. This concept has

been discussed in many previous PPG articles by several authors, and has only been mildly corrected through the use of more powerful desktop computers and sufficiently accurate project software. This assumption is particularly onerous for IT projects as many of an informational technology project’s resources are of expert sta-tus making their availability much

(Continued from page 16) less than the assumed 100%. Thus, as we resource load an IT project, the assumption increases the limitation of a valuable outcome, i.e., a true critical path. There are many that desire the CPM to continue and even improve. A fine article by Eric Uyttewaal on the Microsoft Project Users Group (MPUG) tries to show how the CPM can be salvaged by a new and improved CPM version he calls 2.0.

Underlying this major assumption of the CPM is that most if not all project decisions come down to the alloca-tion of resources. In fact, the correct application of PROGRAM manage-ment is from the perspective of re-source utilization. Notice that it is the

function of PROGRAM management to deal with resource issues across all their projects that compete for scarce resources. This stems from the fact that most PM (project man-agers) still operate on the CPM as-sumption that resources are theirs and theirs alone. Many engagements have shown that many PM get defen-sive and even angry when their re-

sources even though not being used 100% currently are shifted to other tasks on other projects by their own PROGRAM managers. In today’s tough economic times, using the as-sumption of unlimited resource allo-cation or ownership is simply not practical or even applicable unless under ‘what-if’ scenarios.

The first two assumptions can be handled via a healthy salve of com-puter processing and software that is available to most if not all PM using either commercially acquired soft-ware or by using the available free-ware Internet-based applications. Mr. Uyttewaal seems to indicate that by combining CPM 1.0 as he calls the original DuPont 1960’s version of the method with some aspects of critical chain and even Agile that CPM can be re-engineered and even re-elevated to its former glory. He lists 5 or 6 updates that need to be applied to the aging CPM in order to salvage its value and use in modern day pro-jects. They are:

1. Why is the critical path what it is?

2. Why does the critical path often explain only a part of the project’s duration?

3. Why are there hidden critical paths?

4. Why no one today has unlimited resources?

5. Why the CPM has issues tracing a critical path across multiple sub-projects?

6. Why is it hard to protect the criti-cal path from secondary path im-pacts?

Since no modern day project sched-uling tool solves or even addresses all of these issues, it again leaves the use of CPM in either form 1.0 or 2.0 problematic since most PM are not equipped to deal with these con-cerns and therefore blindly answer the call to provide the CRITICAL PATH regardless of its value or accuracy. How you use the CPM after reading


The Well-Skilled PM (cont.)

http://www.mpug.com/articles/critical-path-2-0/

http://www.mpug.com/articles/critical-path-2-0/


cause of my decision to take a career in a completely foreign direction. Riding on the coat tails of an MBA will get one so far, but experience is still king. (Having both I suppose would be emperor?)

Now that I have identified my true problem, it makes solving it much easier because I can pursue a precise solution rather than wasting time fixing what is not broken. Once this

point has been reached, thinking outside the metaphorical box is ex-tremely helpful. The more options available offer a better chance for an optimal solution. And do not be sur-prised if the option that may seem least likely could turn out to be the optimal solution you have been searching for. That is precisely what I am experiencing with my situation. If you can keep an open mind, you may see that it also happens to you in your own problem solving endeav-or. Just be sure that you attempt to solve the correct problem.


on about 6 months since graduation and I am still banging my head in the attempts to secure a position that is in the direction of where I am looking to go with my career. Changing in-dustry is difficult. This I understand, all too well. But after so long, you begin to reevaluate what exactly is going on to see if there is a problem

to be fixed. I have drafted several cover letters, restructured my re-sume, and rewording happens al-most every other day. But I have been going about this all wrong. I am fixing issues that do not exist. Dig-ging deeper it dawned on me as plain as day. My problem was not with the presentation, structure, or aes-thetics. I have had them looked over by professionals and have worked most kinks out. But peeling back the onion, and admitting to myself which is probably the hardest part, the dis-covery is that my content is the issue. I lack some pertinent content be-


this article is important since you can no longer push the button to create your project’s critical path without remembering these admonitions. This is the frustrating part of knowledge and growth – it hurts. Thus, the decision is left to you, the reader, since you are now aware of the gross assumptions that the CPM makes and if they pose problems for your projects.

While I applaud Mr. Uyttewaal’s efforts, the limitations or misuse of CPM combine to indicate that with-out proper understanding of its weaknesses, application, and value, one can get little benefit from the use of CPM on complex IT projects. Wanting to hold on to something that you have used and understood for years in favor of progress is only natural for many professionals. We all have enough in our working lives, and taking on another ‘cause’ does not seem important especially in light that the bodies of knowledge are still pushing the CPM angle. OK, this is granted; however, remember that at one time, the CPM was con-sidered new and unusable. All ideas have an end of life that is determined by the progress of knowledge and human endeavor. If you are going to continue to use the CPM, do so re-sponsibly by ensuring all the assump-tions and weaknesses are well under-stood by all team members and those key stakeholders to which it might make a difference.

In subsequent articles in this series, we will take up the concepts, princi-ples and applications of CCPM and its strengths AND weaknesses – it is also not totally without faults. The PPG wants to ensure fair coverage and accurate details for all techniques discussed in its pages. The reader is then in a more appropriate position to make informed decisions on which to use.


WSPM (cont) Testing the Waters (cont)



ethical behavior. With all the US and non US regulations that IT organizations are required to adhere to such as: ISO 27001 and the EU Directive on Data Protec-tion, it is critical organizations ensure they have a broad base to stay compliant in all areas. The area of regulatory compliance is one of the biggest pressures for IT focused-organizations. To merely apply a cookie cutter com-pliance framework will be imma-

ture and inconclusive of the indi-viduality of the IT organization’s structure.

Huge fines can be imposed if or-ganizations fail to meet compli-ance controls which stand to rea-son why many organizations are centralizing their compliance oversight within their organiza-tions for a better success rate. IT organizations are looking for a structured approach to achieve this compliance oversight balance which is why they use the Sen-

(Continued from page 17) tencing Guidelines are their framework. An overview of the Sentencing Guidelines is not re-peated here, but they can be found in a previous Compliance Central article.

To set up your IT C&E Program the following steps should be considered at a minimum:

IT C&E Program Setup

1. Research and gather all USA and International regulations pertaining to your IT, physical security, and Records Man-

agement, etc. to meet compli-ance requirements

2. Map regulations into compo-nent areas such as records management, physical securi-ty, systems continuity, human resources management, etc.

3. Determine which IT actions are required by each regula-tion and where they span mul-tiple regulations. Look for any gaps or overlaps in order to ensure complete coverage of

“Huge fines can

be imposed if

organizations

fail to meet

compliance

controls which

stand to reason

shy many

organizations

are centralizing

their

compliance

oversight…”

your compliance requirements while reducing any redundant effort. By grouping regulatory requirements into component areas instead of working with them one by one, you reduce redundant requirements.

4. Identify the minimum set of controls you need to comply with to meet your compliance requirements.

5. Establish a compliance frame-work to track all requirements and component areas. (i.e. an

Excel con-trol spread-sheet.)

IT Risk As-sessment (ITRA)

As dis-cussed in previous articles of the Compli-ance Cen-tral, IT or-ganizations conduct a risk assess-ment tai-lored for their indi-vidual or-

ganization’s unique requirements that are based on their organiza-tional strategic goals and objec-tives. The board of directors and c-level executives are responsible for making strategic decisions, so the pressure is on them to create a strong compliance program. Governmental regulatory man-dates require annual risk assess-ments, but with the rapidly grow-ing and changing IT environment


Compliance Central (cont.)

http://projectgazette.com/archives/pg_apr2013.pdf

http://projectgazette.com/archives/pg_apr2013.pdf



matter.

Internal IT Audits:

Organizations are constantly chal-lenged with an increasing number of IT risks including security threats, new regulatory and legislative compliance and the unexpected disruption to sys-

tem availability. Internal Audits should provide assurance that appro-priate controls are considered, imple-mented and operating effectively to manage IT risks, both today and in the future. During the internal audit, the organization should be assessing their internal procedures and processes to ensure they are in alignment with mandated compliance requirements. Some internal documents and pro-cesses that should be reviewed are:

IT standards

that seems to be the norm for IT pro-jects, MCLMG recommends risk as-sessments should be reviewed and if needed, updated at least quarterly. MCLMG suggests quarterly internal assessments tailored to the organiza-tion’s environment to discover any areas of concern or weakness early in order to put into place strong mitiga-tion plans.

The goal of the or-ganizational IT risk assessment should be:

1. Identify the true risks to the or-ganization based on the organiza-tion’s strategic goals and objec-tives. (Remember, risks are tied to the deliverables or in this case, the strategic objectives are the delivera-bles.)

2. Ensure re-sources and time is allocated to develop mitigation plans for each risk, and that triggers are identified,

3. Risk and trigger plans are man-aged, and

4. Risks are quantified for cost.

MCLMG recommends a Risk Subject-Matter-Expert (SME) to assist in the risk assessment as many times or-ganizations spend a considerable amount of time identify the wrong risks, putting into place mitigation plans that are never carried out and miss focusing on the risks that


Compliance Central (cont.)

Change control

Data security and privacy

IT human capital hiring, on-boarding, training, and retention policies

IT controls design, documentation, testing, remediation, implementa-tion (including training)

IT architecture (operating in the cloud environment)

General computer controls

IT policy and procedures

System design, pre and post imple-mentation reviews

Data conversion, interface, and da-tabase reviews

Sarbanes-Oxley (SOX) readiness

Continuity of operations

Database administration

Computer operations

Physical security

The goal of the IT internal audit should be to:

1. Provide an environment of where the organization can accomplish their objectives,

2. Improve overall operations,

3. Ensure any new compliance con-cerns are addressed, and

4. Ensure an environment to improve an organizations risk management, risk control and overall governance processes.

For any organization seeking to place themselves in a better light and posi-tion of showing their support for strong compliance and ethics environ-ments within their operations, the above suggestions are an excellent place to begin such efforts. We will be discussing additional activities and actions that can further an organiza-tion’s alignment and satisfactory achievement of many and varied C&E regulations facing modern day busi-ness entities.


emotions and desires of those already thoroughly ‘quagmire-d’ in the prob-lem project. The PW needs to know who was told what, when were they told, and what was the meaning and/or content of the communications. In some cases, the environment for whispering has been so dealt a toxic poisoning from the discussions, emails, reports or innuendoes sur-rounding a failing project that the PW has little if any chance of even discov-ering underlying causes given that the necessary information has been al-tered, hidden, erased, or locked-down by those seeing the whispering activi-ty as tantamount to a police investiga-tion. Some of this communication will be impossible to prevent, but the PW must determine as best they are able as to its impact before moving to far into the muddy swamp that is the troublesome project.

Finally, the PW should know if the project will continue to execute dur-ing the whispering process or will it be paused until the results of the whis-pering analysis are known. A dynami-cally moving project is harder to ‘pin down’ than one that has been placed on hiatus since the project parame-ters are not changing and the whis-pering process will not skew the pro-ject’s normal execution due to the inferences of those watching the ac-tions or investigations of the PW. Large, complex project cannot be stopped unless under the most dire of conditions, but the PW must know the working conditions under which he/she is going to have to uncover the reasons for the project’s dire straits.

Once these pre-whispering character-istics are clear to both the PW and the engaging stakeholder(s), the next ma-jor phase of the IT project rescue can begin. In our next article, Part II of the IT Project Rescue, we will provide the next step any professional PW should take to better understand their pa-tient before proceeding to a differen-tial diagnosis. Join us for this im-portant discussion.


first evident; however, by discovering the acceptable outcomes that the engaging stakeholder(s) is willing to stomach can provide volumes as to their true reason for beginning the whispering process in the first place. Some stakeholders will want the PW to only suggest remediation recom-mendations in that the project cannot or will not be terminated regardless of project status or problem profile. The PW must ask and be sure of the accu-rate answer to this question. There is little value in suggesting an action that has little if any chance of being ac-ceptable to the engaging stakehold-ers. The possible outcomes are usual-ly:

The project can be salvaged given the provided constraints by the en-gaging stakeholders,

The project can be salvaged, but not within the provided constraints,

The project cannot be salvaged re-gardless of provided constraints, or

The project should not be salvaged given the need for its existence is no longer is viable.

Please understand that are numerical-

(Continued from page 18) ly a larger number of possible out-comes; however, these are the four primary outcomes that lead to either a termination of the whispering activi-ty and the project, or an implementa-tion of the whispering remediation steps with a probability of successful reclamation given the amount of addi-tional resources necessary to com-plete the recommendations. In all cases, though, the PW should be re-tained for a short period after the whispering report is delivered in order to act as an implementation consult-ant. However, as with the use of an external PW, in no case should the PW be considered a candidate for the whispering remedial plan execution manager. Any hint of this could taint the PW’s objectivity and further exac-erbate the problematic situation. In addition, no other Project Manager (PM) from the PW’s firm or organiza-tion should be considered as well. This will completely eliminate any possible contamination of the PW’s recommendation being based on pos-sible future revenue for either them-selves or their firm. This should dis-courage the “Enron syndrome” that occurred when there was too much collaboration between the company (Enron) and its financial and manage-

ment consulting advisors.

The third pre-engagement con-cern that a PW should uncover is the content and voice of any com-munications sent to the faltering project’s current stakeholders that include the project team and organiza-tional manage-ment. The content and/or intent of these communica-tions is paramount to dealing with the

The Project Whisperer (cont.) Rescuing an IT Project



gether closely.

Daily stand-up meetings (especially in the Agile/Scrum approach — 15 minute stand-up meetings to de-termine progress, plan for the day and any required assistance)

Empower the team: built-in trust, sustainable pace, swift velocity, work reflection. Responsibility placed on each member of the Scrum team to deliver functional products quickly.

Requires more up-front testing by the developers to ensure that the product is delivered bug free.

May not be the best solution for an industry that requires significant quality assurance planning and documentation.

Incremental releases of features (not a flip-the-switch approach).

Might not require planning far in advance (however, there is a cave-at to this, if you have to follow the federal budgeting life cycle per OMB-based policies and guidance)

Could be a viable alternative to the waterfall approach for large pro-jects with significant integration and planning. Agile is beginning to change popular opinion that it is not just for smaller projects. If a larger project can be broken into more manageable chunks, Agile could be the best solution.

Not all requirements must be final-ized before starting the work.

Requirements can be modified / adjusted between sprints.

Is not a way to avoid documenta-tion, but emphasizes the need to document only what is required.

Waterfall Methodology

‘Slowsky’

(Continued from page 19) Based on a system development life cycle approach (SDLC)

Longer term planning effort.

Work is performed sequentially — planning, development, testing, deployment, etc. (i.e., the water-fall)

Generally business functions con-ducted separately from develop-ment functions (e.g., requirements developed and handed off to de-velopers for implementation)

Project status meetings / control gate meetings at the end of each life cycle phase to verify that the project is on track and ready to move to the next sequential phase; daily meetings are not a require-ment for Waterfall.

Responsibility of the project is di-vided amongst the team based on functional areas of expertise.

Testing is performed at various stages of development. However, the main focus of testing is after the completion of the develop-

ment of the product when it is ready for final testing. Generally, in a Waterfall approach, testing is conducted at the completion of the development period with the ex-pectation that there will be bugs that will need to be fixed. Howev-er, waiting this long to “flip the switch” means that there might be a possibility of significant errors that could impact the project.

Emphasis on documentation and significant planning up-front. Big on documentation / processes

Long time to project completion (6 months – multi-year)

Flip-the-switch deployment

Requires advance planning; chang-es to requirements much more costly.

The real question or issue is, can large software and manufacturing projects (like healthcare.gov) be de-veloped with Agile type methodolo-gies; and is there a role for the pro-ject scheduler in the Agile world? Let us tackle that next time.

The Master Scheduler (cont.)

Agile vs. Waterfall Scheduling



The project management disci-pline now realizes that all pro-jects are bounded by these con-straints, and the balancing of these constraints is an important responsibility of PM.

These project attributes lead to the following questions:

1. Why are we doing the pro-ject?

2. What are the boundaries of the project due to the defined pro-ject con-straints?

3. What are the project deliv-erables?

4. What is the work to be performed to produce fit-for-use deliv-erables to the customer?

No matter how complex or large your project is, if the PM cannot go back to the basic questions: what are the fit-for-use deliverable and the scope of the project, then the PM and the team has the tendency to veer off course down the path towards project failure.

An inexperienced PM can get surprised when they become aware that the project’s schedule is 4 weeks behind or the custom-er refuses to sign off on the deliv-erables. Many times the PM will tout off all the risks they see when in retrospect the risks are not risks at all, but unskilled PM effort. In an attempt to draw attention away from themselves, the PM creates a reason for their


The Line in the Sand (cont.) Is Poor Project Management Ethical?

poor planning based on events that could not have been seen and therefore mitigated. Some of the reasons for the failed project might contain a good portion of factual information; however, the PM tells the story in a manner that supports their position that they were the victim of unfore-seen events.

We have all seen poor project planning or unfocused planning

lead to wasted resources, team member conflict and eventual project failure. I chuckle at the times that team members come to me as the Risk Manager and ask me to put the PM on the Risk Register as a project risk with the mitigation plan of needing more training for the PM!!

MCLMG offers some simple fun-damentals for coaching inexperi-enced PM:

The PM must understand the fundamentals of “fit-for-use” deliverables to realize the basic requirements of the project.

The PM must adopt the con-cept of a deliverables centered project management method-ology and teach the entire team how to understand this concept.

The PM must understand the project’s primary constraints (scope, time, cost, quality, and risks), and how they must be kept in equilibrium in order to

produce the defined ‘fit-for-use’ deliverables.

The PM should understand the importance of risk manage-ment in the reduction of uncer-tainty that surrounds decisions through the application of valu-able information.

I hope this article will challenge you as a PM to ensure you are not playing the victim or blaming unknown risks for less than ade-quate project management skills. Many times admitting to yourself that you need additional training as a PM is the first step towards improving your project success rates.

“We have all

seen poor

project

planning or

unfocused

planning lead

to wasted

resources,

team member

conflict, and

eventual

project

failure.”



recent very public and exposed USG’s failed healthcare.gov web site roll-out was a failure of meth-odology not technology since pri-vate sector web sites exhibiting more complexity, higher hit rates, and far more choices were in place and generating billions in revenues for their respective owners. The report laid the fault at the twin feet of bureaucratic incompetence and poorly defined requirements. How often have we heard these two causes for the failure of USG IT projects? There are audits and reports going back almost 30 years telling this same story that continues to this day – unwavering, unfaltering, and un-resolved.

4. The ESP Solutions Group in a 40 page scathing report entitled, “Why 70% of Government IT Pro-jects Fail” laid the blame on two (2) undiscovered or heretofore unrevealed reasons:

a. Lack of buy-in from key stake-holders especially from data providers, and

(Continued from page 21) b. Lack of interoperability of pro-ject deliverables comprising the total solution.

The report suggests that the lack of buy-in manifests itself by those impacted by the projects becoming unwilling to change their current processes and processing habits necessary to provide the required data to support the new solution. The second reason arises that the solution components while satis-factorily workable on their own, but fail to work together seamless-ly.

5. A significantly detailed report by the Professional Services Council dated June 5, 2012 on the use of Federally Funded Research & De-velopment Centers (FFRDC) by the US Government does not even correct the project failure problem. The reports details that the use of FFRDC for over 60 years needs to be broadly re-vamped since they are not return-ing the value to the public taxpay-er they once were touted to pro-vide. For example, in 2012, the USG signed a US$1.2 Billion con-tract with the MITRE Corporation,

a US-based non-profit entity, to design, devel-op, and operate a FFRDC specifi-cally for the USG’s Depart-ment of Health and Human Services (HHS) subdivision in charge of the newly re-vamped US healthcare sys-tem. The Cen-ters for Medi-care & Medi-caid Services (CMS) contract-

ed with MITRE to provide ad-vanced modernization innova-tions to (quoting from the MI-TRE’s CMS Alliance to Modernize Healthcare (CAMH) web site):

a. Strengthen the healthcare system through innovation,

b. Build capacity of nation’s health infrastructure and workforce to adapt to change, and

c. Accelerate pace of translating scientific discoveries into prac-tice.

In spite of this huge investment, CMS and MITRE together were unable to stop the nightmarishly failed roll-out of the now infamous healthcare.gov web site on Octo-ber 1, 2013.

6. Finally, a broad smattering of re-ports, audits, studies, and re-search papers from IBM, Geneca, McKinsey, the Portland Business Journal, KPMG New Zealand, and the Canadian Government found that IT projects were over-budget, provided less than expected re-sults, failed to meet stated objec-tives, lacked usable business out-comes, and even simply failed outright. These disclosures can easily be found with a simple Google or Bing search on “high failure rates of government IT projects.” The PE suggests that the reader do their own study and fact gathering.

So with the above listings providing the basis that IT projects fail at an alarming rate, and these failures are greater in the public sector than in the private, the PE was able to inves-tigate and draw some conclusions about this increased lack of produc-tion of the project’s ‘fit-for-use’ de-liverables. The facts are evident, co-


The Project Eye (cont.)

The High Failure Rate of US Government IT Projects



pious, and scattered across the entire globe without respect to continent, government type, or methodology utilized in the project’s delivery phase. The conclusions and solutions are more complex, but understanda-ble. This PE column will finish up this edition with the conclusions that can be drawn from the above research and many others that could not be included due to space and the read-er’s patience while the next PE col-umn will take a step away from its investigatory charter and discuss some of the possible solutions. The PE will return in January with a very interesting and eye-opening investi-gation as to why the USG’s ACA healthcare.gov roll-out went so awry.

The PE seeks to draw the following conclusions about the higher IT pro-ject failure rates amongst the world’s governments when compared to similar projects in the private sector. In doing so, the PE is not attempting to cast any dispar-agement on the government work-ers or contractors since much of the conclusions illus-trate that the problem is system-ic with the manner in which govern-ments operate the world over, and not due to any one group or cast of players. The bottom line is that government IT projects fail at a high-er rate than other organizations or industries IT projects so the heart of the issue must be how governments operate or function as opposed to private sector entities.

(Continued from page 56) So with these ground rules, and a statement that these reasons are purely anecdotal in nature or non-empirical if you so choose, let the reasoning begin:

1. The primary reason for the higher failure rate has to do with the one issue that separates the public from private sector mindset, and that is, in the public sector, the money being spent is not the or-ganization’s money. In other words, it is other people’s money (OPM). In the private sector, the funds belong to the firm itself, if truly privately held, or to the firm’s stockholders. Spending and decision making is therefore radi-cally different since governments are not managed as ‘for-profit’ entities. This is crucial in how pro-ject management is enacted, exe-cuted, and implemented. If a pri-vate sector industry was told that their funds were not from stock-

holders or the firm’s owners, but some very large association of faceless providers that had no choice but to fund their opera-tions, and that even if the alloca-tion or utilization of those funds resulted in no business value the

employees could not be fired, how would they alter their deci-sion making profiles?

Impossible to say or determine? Not so. Simply look to how the Savings and Loan industry in the USA reacted when they were told almost precisely this during the 1980’s S&L Crisis that resulted in at that time the largest bail-out of private organizations by the USG to the tune of over US$160 Bil-lion. The S&L organizations were basically told that they needed to loan regardless of risk and that if they failed, their failures would be repaid. Yes, I know that such a simplification may not be 100% accurate, but it is very close as the PPG research department had access to some of those closely involved in that “financial bub-ble.” Dare we mention the same exact support of the mortgage industry produced the 2006-2008

global mortgage bubble?

So when all risk of failure both organi-zational and per-sonal is removed as is evidenced by the recent very public failure of the USG healthcare.gov roll-out and no conse-quences were me-tered out, and in fact the same com-pany that dummied up the initial web site was given the task of repairing it. In addition, the

head of the USG department for which the roll-out was entrusted is still working along with her en-tire staff.

2. The other major difference be-






tween the public and private sec-tors that largely contributes, in our opinion, to this higher failure rate of government IT projects is that of the limited planning hori-zon of public sector organizations to that of the annual or nearly annual budgetary mandates im-posed by the manner in which governments are allocated their funding for projects. When plan-ning is no longer than the next appropriation cycle usually a sin-gle year in length, the value of planning for the impact of project selection over 3, 5, or even longer is lost on the public sector manag-ers. While some will point to the fact that some government pro-jects are given an initial funding period of one year with 3-4 op-tion years that this is not true; most know that nothing beyond a year or to the next budget is even marginally guaranteed. In many cases that we have personally been involved with, the prime contractor is only counting on getting the first year amount of the project funding and does not really plan for obtaining the subsequent option years due to the large number of govern-ment projects that fail during this first year re-sulting in the change-out of the prime contractor for someone or some entity new and ‘with a better grasp’ of the pro-ject’s true objectives. We have been in meetings where the proposal for the government’s state-ment of work is based on this very fact.

For many this does not seem plausible, but espe-cially with the USG’s al-

(Continued from page 57) most mandated utilization of firm-fixed-priced (FFP) contracts that place the entire financial risk on the prime contractor, this motiva-tion to worry only about the first year’s problems since ‘we may not be the prime’ next year has a tendency to demotivate the awardee towards solutions that could really provide a resolution to the government’s dissatisfac-tion with the status quo and to only do what is necessary to ob-tain the approval of short term deliverables that as was stated above do not integrate well with other project components. This is especially true when the prime contractor enlisted the aid of mul-tiple sub-contractors many of which are small to medium (SMB) sized businesses. In fact, the USG mandates that a certain value of its contracts are awarded to SMB firms in a concept called ‘set asides.” These pre-allocated funds are for projects that must be awarded to specifically identified SMB owned by veterans, minori-ties, or specially labelled firms.

The impact of this mindset is such

that the IT project’s prime con-tractor is not sure that they will be working on the project when the main deliverables are set for completion, and that they must use specifically identified firms regardless of these firms’ track record or proven performance. In several actual engagements that the PPG research staff are person-ally aware of, this mindset was discussed in open meetings and planned into the project’s execu-tion and management.

These two reasons can usually be discovered as either primary reason for or at least contributory towards the higher failure rate amongst gov-ernment IT project due to their crea-tion of a lack of ownership in both the government customer and/or the contract’s prime contractor. When coupled with the fact that there is little consequence for failure on ei-ther the government side or contrac-tor side, the removal of risk potential for failure permeates the attitudes of the project’s stakeholders. The PE believes that this lack of ownership due to the application of OPM and limited budgetary planning horizons forms the major causalities that are at the heart of many government IT project failures. Ownership in the project’s outcomes and ownership of the success or failure when limited by these reasons can and usually does produce the very fertile growth medium in which government IT pro-jects find their crop of failures that grew from the seeds of these mind-sets.

In the next PE, the PPG research and investigation staff will finish this dis-cussion with some possible solutions for the above causal relationships between the indicated failure com-ponents and government IT projects. We look forward to completing this particular investigation. Please enjoy your holiday season, if applicable.





nately, most agencies have post-poned or pushed out responses for proposals (RFP) due to budget con-straints. Regardless of the limited supply of RFP, most companies have had to lay-off their employees simply because it was too expensive to re-tain them until the work material-ized.

“An October 2012 poll of more than 140 financial executives showed they shifted the whole way they do busi-ness. More than 40% still face high or very high uncertainty. They've been buffeted by an onslaught of unex-pected changes to their business, such as bankruptcies of key custom-ers or suppliers, loss of bank loans, and decreasing demand.”[1] In many

cases the increase in employee health care costs has caused employ-ers to lay off their employee or to have them become part-time. We continue to hear the increasing un-employment numbers. Welcome to our new normal!

With so much uncertainty businesses are trying to do more with less! They are striving to maintain a low over-head, to remain flexible with con-tracts and managing their employees and trying to keep from paying high-er health care benefits. So it makes more sense to have their employees do more work for less pay or to hire employees only on a part-time basis in order to keep costs low.

It is not surprising that with given so

(Continued from page 22) much uncertainty with the health of the economy, the work force etc. that those workers between the ages of 45 - 65 are being forced to delay retirement due to the recession. The recession has impacted our economy and workers in many areas from the difficulty to finding new jobs to the difficulty to continue saving for re-tirement or the difficulty to afford health care, utilities, college educa-tions etc.

“More than four years after the offi-cial end of the Great Recession, many American workers are still feel-ing the effects from the worst eco-nomic downturn since the Great De-pression. Indeed, the current labor force has about six million fewer workers than had been projected in 2009, largely due to the Great Reces-

sion. It is tempting to settle for a new nor-mal, but the economy will not be fully recov-ered until today’s missing workers are back at work. “[2]

Unfortunately, in spite of the promising news on the hiring front, “the steady-state un-

employment rate is currently ex-pected to remain flat at 7% over the next 6 months implying a weaker ‘steady-state convergence dynamics’ going forward and an unemployment rate still above 7% by March 2014.”[3]

All of this information is to confirm that the recession has had a lasting effect thus generating a new normal for us to assimilate to. The conse-quences of several years of high un-employment, falling incomes, in-creased cost of living have had a domino effect throughout our coun-try. Job loss and falling incomes can force families to delay or forgo a col-lege education for their children. Credit markets frozen and lack luster consumer spending can stop the cre-

ation of small businesses. On the other hand larger companies may delay spending on R&D or have a reduction of work force in order to survive the new normal.

This new normal means we need new ways to grow businesses, new strategies for job searches, new methods for managing risks in the work place and especially new ways for managing change!

[1] http://useconomy.about.com/od/criticalssues/a/Top_Five_Economic_Trends.htm Amadeo, Kimberly, Top 5 Economic Trends: What is the Future of the U.S. Economy? February 22, 2013.

[2] Greenstone, Michael and Adam Looney, The Hamilton Project; The Lasting Effects of the Great Reces-sion: Six Million Missing Workers and A New Economic Normal, Sep-tember 12, 2013.

[3] Barnichon, Regis, Unemployment Projected to Drop to 7.3% but Future Recovery Compromised Absent Im-provements on the Hiring Front, Sep-tember 4, 2013.

————————————

Ms. Shelley A. Mitchell:

Attended school in Boston and loved going to the Charles to hear the Bos-ton POPs. Ever since I have tried to emulate my work to a "Project Con-ductor" where I integrate, communi-cate, implement, and report all pro-ject data harmoniously as possible in order to help my customer make the best informed decisions for the work of the program. Currently re-siding in Northern Virginian and is a seasoned project manager who has supported commercial and govern-ment agencies’ projects includ-ing supply chain, IT, Technology and Research.

Ms. Mitchell has a Masters Degree, and holds a PMP® and PMI-RMP® credential from the Project Manage-ment Institute of Newton Square, PA.

Shelley A. Mitchell (cont) The New Normal!

http://www.adaptiveplanning.com/news/215/61/Upbeat-View-From-Nation-s-Finance-Execs-Prior-To-Election-Day-Fiscal-Cliff-Budget-Deficit-And-Job-Creation-Remain-Concerns/

http://useconomy.about.com/od/demand/a/demand_primer.htm

http://useconomy.about.com/od/criticalssues/a/Top_Five_Economic_Trends.htm





public procurement? In the EU, the European Commission and the courts are tightening up the procurement regime. It is now easier than ever for losing bidders to challenge procure-ment awards – and they are doing so. Departments are consequently seeking more up-front certainty and less flexibility. In an agile project, given three parameters – time, mon-ey and scope – you cannot fix all three, although that is exactly what a regulated procure-ment exercise seeks to do.

Secondly, govern-ment ICT projects would need to be ex-empted from the Freedom of Infor-mation Act. Knowing that eve-ry written document could be dis-closed makes project teams cautious. They will be wary of saying or doing anything that might look bad, so they are wary to “get involved” in the way agile requires. But the requirement of openness is so widespread within government, that lack of transparen-cy automatically appears sinister.

Thirdly, government would need to conduct a massive training exercise (and probably recruitment as well) to ensure that project teams can make agile work with suppliers. The main point of failure in a large develop-ment project is usually the people, not the process. Major training and

(Continued from page 23) recruitment exercises are unlikely because departments are facing huge pressure to reduce head-counts and budgets. They will have to make do with smaller retained project management teams.

Fourth, all public sector management structures are designed for central-ised decision-making. Government is set up so that every decision of any importance is flowed up to senior levels. Under the current UK govern-ment structure, even more power over projects is reserved to the Cabi-

net Office. But it is a key part of agile processes that decision-making (over requirements, for example) is flowed down to small devolved teams who can react quickly and adjust to new scenarios. Any requirement to go through management hierarchies (as will inevitably be the case in central government) is like kryptonite to agile-managed projects.

Next, project teams should be freed from the fear of failure. Try telling departments not to worry about re-serving a right to claim if something goes wrong. Lawyers are not the problem here. Any government body whose project is not a resound-

ing success gets a double kicking: public opprobrium via media scrutiny and then criticism from the National Audit Office or Public Accounts Com-mittee for not having sufficiently effective remedies that make the service provider pay for the damage to the public purse. Under agile, the customer becomes centrally involved and so apportioning blame is hard. And agile contracts have less clear contractual delivery obligations or remedies so enforcement and recov-ery of loss or damage can be a prob-lem.

Finally, there would need to be a change to the mentality that every penny that a department proposes to spend over the next year is scruti-nized to death and required to be accounted for up-front. Government customers need to know in advance what the cost of a project will be. Departments have very tightly man-aged and approved budgets that cur-rently struggle to cope with the open-ended charging basis that agile im-plies.

My concern is that the nature of the public sector environment means that agile methodologies are harder to deploy successfully than in the private sector. Within government, processes are bureaucratic, decision-making is slow, there is a lack of un-derstanding of agile in ICT depart-ments, and there are too few em-powered business representatives. The real risk is of getting the worst of both worlds: the bureaucracy of wa-terfall and the vagueness of agile.

—————————-

Alistair Maughan is a partner in the London office at Morrison & Foerster, an international law firm. He is a prominent adviser on public sector ICT projects in the UK. Follow him on twitter at http://twitter.com/ICToutsourcelaw

Alistair Maughan, Esq. (cont) Agile Will Fail Government IT Projects

http://twitter.com/ICToutsourcelaw%20

http://twitter.com/ICToutsourcelaw%20



the law with integrity and fair-ness to all.”

Mr. Wefel admits that inappropriate criteria were used to screen the ap-plications for tax exempt status, to include the Tea Party and other ap-plications based on their names or policy position by the Exempt Organi-zations (EO) unit of the IRS. This in-appropriate criterion was allowed to remain in place at the IRS for more than 18 months and the reports says that the IRS knew it was in contradic-tion to their mission statement.

The IRS website outlines changes that the IRS will do to ensure ac-countability and chart a path for-ward. The main points of Mr. Wefel’s report are discussed in following:

1. Accountability:

New leadership has been in-stalled across all five executive management levels.

(Continued from page 27) An Accountability Review Board has been put into place to pro-vide recommendations on any additional personnel actions.

2. Fixing the problems with the re-view of applications for tax-exempt status.

A new voluntary process to help

certain applicants gain fast-track approval to operate as a 501(c)(4) tax-exempt entity if they are

being reviewed for advocacy questions and have been in our application backlog for more than 120 days.

Suspension of the use of any “be-on-the-lookout,” or BOLO lists in the application process for tax-exempt status.

3. Review of IRS operations and risks.

Establishment of an Enterprise Risk Management Program as a common framework for identifi-cation and assessment of inter-nal risk.

Comprehensive, agency-wide review of compliance selection criteria.

Internal and external education about the role of the National Taxpayer Advocate in assisting taxpayers in resolving problems they encounter with the IRS.

[1] Daily Mail, June 24, 2013

rent USG administration has the abil-ity, knowledge, or will to pull out of this spiral so the ultimate crash of the much touted ACA roll-out will be both loud, dramatic, and very very expensive to the US taxpayer.

What are the lessons to be learned from this overly public approaching catastro-phe? Well, it is wrong to count the cost before the events occur; however, from a technological or project management perspective, the one solution that was not tried, but should have been was the garnering of those in the US Internet

(Continued from page 28) community that already have a prov-en track record in designing, devel-oping, and deploying such web and retail solutions. Unfortunately the

contract was awarded to a company without any history of creating such world class sites. All world govern-ments should take careful notice of

this current event – a ‘not invented here’ attitude can be both costly, ineffective, and publically humiliating. Utilize the resources in both project management and technology that have ‘been there, done that’ experience regardless of the initial seemingly ‘loss of face’ admission that we need help. There is nothing wrong in asking for help before the situation becomes untenable; it is only afterward that such an omission becomes laugha-ble. Lessons learned, readers, lessons learned.

Current Events I : The IRS Tax Exempt Scandal (cont)

Current Events II: The ACA Web Site Launch (cont)

http://www.dailymail.co.uk/news/article-2347734/Danny-Wefel-IRS-targeting-included-terms-Israel-occupy-progressive-tea-party.html#ixzz2kYXuK03Y



sessment to relevant auditable areas within the organization. Applying a RBIA enables senior management to see how strong the risk framework is within the organization and to pro-vide to the Board that the risk man-agement processes are managing risk effectively for the ultimate achieve-ment of the organization’s goals and objectives.

The goal of an RBIA is the assurance that the organization has a plan in place to identify, assess, and manage risks within the organization that could prevent the intended goals and objectives. By conducting the RBIA, more emphasis is on risk potentials and risk management.

We all know resources are scare and often perform multiple tasks within our organizations. By knowing you will be conducting an organizational risk assessment within a planned timeframe, resources can be allocat-ed to conduct the risk assessments, develop risk mitigation plans, and

(Continued from page 29) ensure triggers are iden-tified through causality analysis. If an organiza-tion does not implement the risk assessment as a planned activity with milestones throughout the year, risk and trigger plans are not managed as they should be. By the implementation of well-structured risk as-sessment the RBIA fol-lows a well-laid out and defined process of business enhance-ments and improvements through the application of sound risk man-agement and mitigation activities.

Additional benefits that can accrue to the organization performing a RBIA are:

Overall improved operations

Assurance that any new compli-ance concern is addressed

An improvement in governance processes

Knowledge share to and from sen-

Goal of Risk Assessment and the RBIA (cont.)

ior management

Involvement from the “tone at the top”

Incorporating risk management prin-ciples into organization-wide strate-gic planning provide an overall gov-ernance structure established by the organization. The risk management strategy is communicated to all levels of the organization thereby achieving a higher level of collaboration and commitment that can directly result in the improvement of business pro-cesses and strategic activities.



footprint.

Does this mean that public or not for profit organizations do not require strategic projects? NO! Any organization regardless of profit motive demands strategic projects be designed, funded, and completed since it is these strategic projects that seek to achieve the mission (public) or vision (private/commercial) ob-jectives of the organization. Mis-aligning projects that are in reali-ty tactical or operational and treating them as strategic is a double loss for the organization since the funding of strategic work requires the application of very scarce resources and talent, but there is also the normally unaccounted for ‘opportunity cost’ that must inevitably be counted by not doing the true strategically valuable project work. While tactical and opera-tion work is important and nec-essary, they do not move the organization towards the obtain-ment of the stated mission or vision profile.

How are strategic and tactical projects identified so they can correctly be classified for both funding and support? There are several metrics against which an organization can measure the strategic nature of a business case or proposed project’s state-ment of work. These help to un-cover the actual focus of the project’s effort:

Are the proposed project’s outcomes producing delivera-bles that directly address the mission or vision?

Is the proposed project’s direct sponsor a member of the or-ganization’s senior leadership team (SLT?)

Does the proposed project’s

(Continued from page 30) business case directly ad-dress an unresolved enter-prise level issue?

Will the proposed project’s deliverables alter the man-ner or expand the current business practices?

If the answers to these questions are ‘No,’ or ‘we are not sure,” then it is like-ly that this a proposed pro-ject that is masquerading as a strategic initiative when in reality it is either tactical or operational impacting. Better to discover this misa-lignment in the project chartering or business case phase then after the project has been funded, staffed, and scheduled. At that time a certain amount of busi-ness inertia takes over and the project is unlikely to be altered or refocused, and the double charges of direct expenditures compounded by the project’s opportunity cost begin to accumulate.

If this condition is occurring at your organization, the time to begin the remedia-tion is past due. For every project that is called strate-gic, but is in reality not, the clock is ticking on an organi-zation having to stop, ad-just, and then correct its mixture of vision or mission oriented project work. Begin with a review of your organization’s past two years of project instantia-tions. Apply the above met-rics to determine if indeed you are misaligning your projects into the strategic category when in fact they are not. Do not forget the double costs of making such wrongful characterizations. It can add up very quickly against you.

PPPM Environment - Strategic vs. Tactical IT Projects (cont)



man’s innumeracy, or ability to rea-son intuitively as it differs from ra-tional choice theory. They stated that CB or heuristics are simple for the mind to compute, but often intro-duce ‘severe and systematic errors’ to the de-cision mak-ing pro-cess. The types of CB include three ma-jor classifi-cations, but are not limited to:

Decision making, belief, or behav-ioral biases,

Social or attribu-tional biases,

Memory errors and bias-es,

Each of these classifications or types of CB contain a large number of spe-cific biases. For example, in the first category, decision making biases, there are listed over 90 individual biases, and over 25 social biases. According to most expert sources, these are not all of the CB that hu-mans sometimes find themselves in the clutch of their fog or obfuscation. However, as mentioned in previous “Well-Skilled PM & BA” articles, un-derstanding the basis of one’s biases is the first and most important as-pect to dealing with and countering any negative impact the CB might be responsible for producing. Since we are interested in decision making, future articles will address these bi-

(Continued from page 32) ases as the category of interesting dissection.

To prepare us for a more in depth discussion of cognitive biases, the short listing of some of the individual biases might be an interest manner to show how many biases humans

can become afflicted with while try-ing to make sound business deci-sions. Some of the favorites are:

Availability cascade: a self-reinforcing process where a collec-tive belief gains additional plausi-bility by being more frequently repeated in the public discourse,

Backfire effect: when a personally held belief is strengthened in react to an increasing amount of discon-firming evidence,

Clustering illusion: over-rating or expecting small runs, streaks, or clusters in large samples of random datasets,

Confirmation bias: tendency to attribute, focus on and remember information in a manner that con-firms one’s own perceptions or preconceptions.

Framing effect: eliciting different conclusions from the same infor-mation depending on how or by whom that information is present-ed,

Frequency illusion (Baader-Meinhof phenomenon): an illusion in which a word, name or other item that has recently come to one’s attention suddenly seems to appear with improbable frequency shortly afterwards.

Hindsight bias: the tendency to see past events as being predicta-ble at the time those events hap-pened.

Hyperbolic discounting: tendency to have a stronger preference for more immediate payoffs relative to later payoffs where the tendency increases the closer to the present both payoff are positioned in time.

This should provide enough fodder and interest for those of you wanting to dig digger into understanding how your mind, attitudes, perceptions, and emotions can derail your deci-sion making. These will be discussed also from the perspective of how to spot and exploit them in others.

Next month’s column will begin this journey by discussing the biases that impact our decision making and be-havior. These biases include such ominous labels as the backfire effect, blind spot bias, curse of knowledge bias, or even the odd sounding, ludic fallacy bias. Join us for this inter-esting and hopefully insightful series of articles.

Understanding Cognitive Biases, Part 1 (cont.)



and desires of those for which the stove will be put to use. This is what is known as the need satisfaction / tool utilization concept of customer behavior. Tools either in the form of products or services are mere proxy or implements of the real satisfaction of customer needs or desires. Prod-ucts and services are simply the means to an end.

In addition, ITIL requires the service provider to achieve an inti-mate under-standing of their customer needs, in this case IT services, in terms of what these needs are, when and why the occur. Also, a clear under-standing of exactly who is an existing or potential user of these IT ser-vices provided by the IT ser-vice provider is required to support the service design and implemen-tation. Within these initial clarifications is the need by the service provider to also under-stand the broader context of the current and possible future contexts of the marketplace in which the ser-vices will be provided to current and potential service users. This demands that any service exists in this context and not in a vacuum or isolation, but within the customer’s utilitarian cul-ture based on the defined benefits that customers have that are to be satisfied by the purchase of the ser-vice provider’s offerings.

While all of this is high sounding and

(Continued from page 33) wonderful, as with most methodolo-gy implementations, the devil is in the details. So in order to support these ideas, ITIL provides a training program to certify individuals that have studied, experienced, and can provide the ITIL service objectives as ITIL has been defined by the UKG. These certifications are modular in design and exist in a tiered structure to provide certified professionals that can assist organizations in their integration of the ITIL practices. The

levels of what is called the ITIL Quali-fication scheme are:

1. ITIL Foundation

2. ITIL Intermediate

3. ITIL Managing Across the Lifecycle

4. ITIL Expert, and

5. ITIL Master Qualification

Each level except the Master level requires a knowledge achievement as determined by the taking of speci-fied educational sessions followed by successful passing of an examination component. Only the master level requires a certain experience re-

quirement of at least five (5) years in leadership, managerial, or senior advisory roles. The upper two levels are not exam based, but require a passing of an assessment review and/or acceptance of a self-determined work package consisting of a detailed presentation of how the candidate was able to apply their ITIL knowledge and experience to solve the business issue under considera-tion.

The identified benefits that are sug-gested will flow to an organiza-tion that imple-ments the ITIL service man-agement envi-ronment are:

IT services that better align with business priorities and objectives,

Known and manageable IT costs,

Increase busi-ness productivi-ty, efficiency, and effective-ness,

Financial sav-ings from im-proved re-source manage-

ment and reduction of rework,

More effective change manage-ment,

Improved user and customer satis-faction with IT based services, and

Improved end-user perception and brand image.

In our next article, we will review the next IT governance framework called Control Objectives for Information and Related Technology (COBIT) which is in its 5th rendition. See you then.

Preview of the AXELOS ITIL® (cont.)



of sensor points, data collection, vari-ance analysis, adjustment recom-mendations, and implementation of approved adjustments. Each of these steps require a thorough under-standing of the project’s reason for existence, interaction with the pro-ject key stakeholders including the project team, and result profiles that will determine the level, type, and intensity of any required adjust-ments.

First, the project execution activities will need to be monitored at various points or through sensor touch points where executional data is available. These sensor points can be determined in consultation with the Project Manager (PM) and quality subject matter expert (QSME) if one is assigned to the project. These touch points can be data genera-tion actions such as time and attendance, task completion in-puts, test results, surveys, inspec-tions, or even reports of actual project activity. These sensor points will provide the next item in progress checking an IT project – the collection of raw progress data.

Raw rata must then be analysed since in the collection state is simply facts and not information. The data is structured, vetted, and combined in order to condense the revelations of progress actuals that it may contain. Once the data has been cleaned and structured, it can be compared to pre-defined preferences, benchmarks or base-lines in order to provide the vari-ance information needed for un-derstanding the differences be-tween normal and actual or planned and actuals. It is this vari-ance analysis that forms the basis of all project progress checking value. Without accurate variance analysis against what is consider acceptable no progress checking can be determined. This is the fundamental reason for establish-

(Continued from page 34) ing project baselines in all the five (5) project constraints of scope, time, cost, quality and risk. There are oth-ers, but unless these five (5) con-straints are baselined then no amount of data collection or analysis will achieve much success. It is pre-cisely this value of variance analysis that requires PM to ensure that their project constraints are baselined meaning that they are approved and placed under control.

Once the variance analysis has deter-mined if any amount of significant differences exist, the PM in conjunc-tion with the project team and key stakeholders will need to decide what course of adjustments might be required in order to bring the project back into alignment with planned or expected behaviour. The adjust-ments will require integration with

Progress Checking Your IT Project (cont.)

the existing project execution and thus some impact analysis may have to be completed if the adjustments have the possibility of interference with planned work efforts.

Finally, as with any other approved changes, the adjustments will need to be monitored for correct imple-mentation with a more frequent pe-riod of sensor point monitoring to ensure that the adjustments have had the desired effect. It is very simi-lar to flying an aircraft and making adjustments to altitude, heading, and velocity. A good pilot does not make large moves in order to return to desired or filed flight plans. Like fly-ing, in project management, it is about making ‘small moves, Sparks, small moves.’



The characteristics of a powerful SMM are:

1. The overall goals must be suffi-ciently clear to provide a defina-ble horizon,

2. The plan for achieving these goal, in other words, the objectives must be understood and achievable,

3. The sequence of tasks and activities (in sum-mary form) must be graphically provided in some other form than a normal Gantt chart – suggestion, a landscape image comparable to the difficulty and com-plexity of the project’s task sequence can be overlaid with the sum-mary tasks and interre-lationships,

4. The identified risks must be illustrated to allow for acceptance of possi-bilities and needed miti-gation planning to take place before the risks trigger into reality, and

5. The rewards for com-pleting the project with-in the defined con-straints must be articulated and acceptable.

With these characteristics, how can one create a shared mental model or map? There are several techniques, but the one we find most powerful is the creation of a project landscape. For example, when engaged on a US Navy project as a consultant, a mari-time landscape involving the actual project deliverables to be completed was laid out using the geography of a naval vessel as the backdrop. The progress of the project was depicted

(Continued from page 35) as the building out of a naval warship aligned with the project’s delivera-bles. The analogy of the ship’s de-sign, construction, and equipment installation took on the tasks that the project would need to complete in order to deliver the project success-fully within the agreed upon con-

straints given a launch date needed to send the naval vessel into action.

The SMM took on a life of its own with the team members becoming more and more involved with the map as a proxy for the project’s own progress model. Meetings were very enjoyable and exciting as our work in the real world was mapped to the build-out of the USS Success as the team came to call the naval proxy. Once we explained the parallel na-ture of the project’s plan and execu-tion to the ship’s construction many

of the questions as to what, why and how were circumscribed through the analogy of the ship’s shared model.

Now many psychologists and cogni-tive scientists are going to balk at this concept, but a SMM can be anything that obtains a common perspective of how a project is going to come

together, so to speak. We use imagery that is relat-ed to the project of inter-est, others use their Work Breakdown Structure (WBS), and still others use their schedule’s Gantt chart diagrams. Regard-less of the use of imagery or even simple text de-scriptions, the power of a SMM cannot be over em-phasized. Most all PM have been members of project teams where the details of the project exe-cution are held very close to the minds of the pro-ject management or pro-ject sponsors. This makes gaining acceptance, trust, and motivation from your project team all the more difficult to obtain.

There are many real life examples where a SMM has produced spectacular results, and we close this article with one of the

most powerful from then President John F. Kennedy in a speech to Con-gress on May 25, 1961 on the goal of “landing a man on the moon and returning him safely to the earth…” That simple statement produced one of the most significant shared mental models in the minds of all Americans that it produced a series of innova-tions in many scientific and techno-logical disciplines that produce by-products even to this day.

Wow! The power of a shared mental model. Unbelievable.

What is a “Shared Mental Map?”

Improving Project Successes (cont)



tional formatting that is done to sup-port the following steps. Make your spreadsheet as basic or advanced as your Excel skills allow. The above ta-ble is now the dataset comprising of both the data for the independent variable (N) – the number of UCTP recovered from previous projects that accomplished similar testing activities, and the dependent variable (D) – the amount of actual testing time con-sumed on these historical projects.

Having the dataset in your Excel spreadsheet, it is now time to create a simple scatter plot chart using the above dataset (worksheet2 of the provided Excel file). Selecting the two columns and then going to the INSERT menu and select the Scatter Chart drop down list in which the scatter (XY) chart type should be selected. Your spreadsheet should look some-thing like Figure 1.

The spreadsheet has just created a simple scatter plot diagram or chart where the UCTP (Use Case Test Points) is plotted along the horizontal or X-axis, and the actual time duration values discovered from the historical archives of your organization’s previ-ously completed projects and their estimates is plotted along the vertical

(Continued from page 36) or Y-axis. The resulting plot are a set of 10 points ‘scattered’ along the chart area from the lower left to the upper right. While this is now begin-ning to look like it has value for our estimations, the real ‘magic’ is yet to come, and in reality, the magic is simply knowing how to determine the equation that we can then use for determining the durations estimates on future project testing activities. This estimator provides us with valua-ble information that reduces uncer-tainty in making our duration deci-sions. Such use of simple statistical analysis can provide real benefits over what is normally used – guesses, or best estimates off the top of our SME’s head.

With our data now in place and the scatter plot or chart in existence, we can simply ask Excel to display the trendline which describes the best fit of a straight line (remember this is linear regression analysis) that uses a concept called ordinary least squares

(OLS) calculations. Since our dataset is from historical sources (actual), we call this framework an observational study where we observe the value of (N) and discover the value (D) by actu-al observation of reality. In our exam-ple, we have a database or listing of projects that show an actual pairing of

number of UCTP (N) and the actual amount of testing time taken (D) to complete the testing of each project’s UCTP.

Luckily for us, we do not have to do the work by hand or by manual calcu-lations. We can simply ask Excel to show us the calculated linear regres-sion trendline that is calculated inside of Excel using the OLS process. To see the trendline that minimizes the squared variances between the data points a best fit straight line, select one of the data points in the XY scatter chart and then right click to see the properties menu where you select ‘Add Trendline.’ Immediately a straight line that minimizes the squared variances between each data point and the now displayed trend-line. Figure 2 shows the now dis-played trendline for our dataset and selected scatter chart.

In our final article in this series, we will move beyond this simple display

of Excel charts and actually produce the estimator’s equation that we can use to calculate an estimate of testing duration based on our historical norms. Join us for this exciting conclu-sion. OK, so math and scatter plots are not exciting, I understand. The conclusion will be very spectacular.

Techniques Corner (cont.) - Linear Regress Analysis, Part II

Figure 2: Adding a Trendline to Chart

EXCEL

Spreadsheet

http://projectgazette.com/files/TargetedV_Fig2.jpg

http://projectgazette.com/files/LRA_Example_PPG_Nov2013.xslx



required information

This leaves the accurate new widget accounting information as the only deliverable that will solve the busi-ness case or dissatisfaction with the status quo that was generated by the new legislative mandate. The metrics and quality determinates are those that enable the new information col-lection to be compared with the actu-al production levels as determined by a physical inventory count that is only conducted annually and then only a statistical sampling of the production over a defined period of time. The use of sampling aided by a few models based on linear regression analysis

could set the quality baseline to which the new information generation pro-cess could be benchmarked.

Now for the risk identification pro-cess. With our deliverable and metrics in hand, what is the risk or risks that are tied to the deliverable and could prevent the production of the ‘fit-for-use’ deliverable? In our example, the primary risk would be that the infor-mation does not favourably compare with or fall within the control bands of our quality metric or benchmark – the physical inventory sampling so that we are not able to provide the man-

(Continued from page 38) dated widget accounting information to the government on our next tax filing. This is where most project team members swerve off the path and start labelling any and everything as a risk when in reality they are causes and/or triggers of the risk.

So what are the causes? A risk cause is the event or condition that makes the risk if so triggered a negative im-pact to the project deliverable. What are these causes in our example? Cau-sality analysis in our example would produce those events and conditions that would prevent the generation of the accurate widget accounting infor-mation from being generated. These could be bad modelling, poor model design, inaccurate quality baseline generation, the lead developer com-

ing down with measles taking her off the pro-ject for 8 weeks, a new operating system from Microsoft, or a major update to our statistical analysis software arriv-ing during the project’s lifecycle. These are NOT risks, but causes of the risk being a nega-tive detractor from our ability to generate the accurate widget infor-mation for our tax doc-ument. These are events and conditions

that fall within our normal daily pro-ject management prevue since we were able to identify them and know exactly how to reduce their impact on our project deliverable. Do not con-fuse causes with the risk themselves (the effect).

Finally, what are triggers? Triggers are those events that if allowed to occur have a catalytic impact on the risks themselves. They cause the risk to transform from a potential energy state to a kinetic energy state where the now labelled issue is causing real time negative impact to the project

deliverables. Triggers again are often mistaken for risks, but remember trig-gers are associated with the risk not the deliverable – only risks are associ-ated with the deliverable. Getting back to our example, what are the primary triggers that would cause the risk of not being able to generate the accurate accounting of our widgets to the government on our next tax filing to become a reality if not resolved quickly and cheaply (the two actions applied to any issue)?

In our example, triggers could be a computing failure that prevents the data from being available on time to populate the tax filing to meet the government’s deadline, it could be a weather pattern that takes out our administration offices since we live in a high tornado probability venue, the accounting and analysis division con-tracts a virus that causes data dele-tion and/or security problems, or even a hostile take-over or buy-out by a larger firm. Anyone of these events could trigger the risk into becoming an issue, but by themselves they are not risks since if they do not occur at the right time or in the right recipe, they do not prevent the generation of the accurate accounting information from making it the firm’s tax filing document. Remember, triggers need to be understood so their interrela-tionship, interdependencies, and/or probabilities can be managed to pro-vide another form of risk manage-ment by eliminating their chance of causing the risk to become a reality.

We suggest that you now practice identifying risks, causes, and triggers on both your current projects and other projects that you have been a part of so that you can improve your skills in this area. Good luck, and ap-ply the concepts in this article to help you more effectively identify the risks for which your mitigation resources can more effectively be applied and not wasted on the incorrectly identi-fied risk components.

Risk Concepts Targeted Series (cont)

Identifying Risk Causes & Triggers in IP Projects



The CONSULTANT’S CORNER

Are you SATISFIED with your organi-zation’s project success rates (PSR)? Are you achieving the business value you were told to expect from the implementation of your business, IT, or customer-oriented projects? Are

you happy with how your projects are being instantiated, planned, and executed? Do you feel you are getting your money’s worth from the high compensations be-ing paid for PM and BA professionals? Well, if any of these questions are those that nag at your consciousness or keep you up at night’s then MCLMG Consultants can help answer these questions for you.

With experience in project management and business analysis of at least 20 + years, our consultants will come on-site or via teleconferencing provide a custom-ized evaluation of your current PM or BA environment detailing its present state of maturity and suggesting up to a three year plan for improving both your project success rates or contract persistence percentages.

Why continue to whine about your PSR to other associates or executives? Doing the same thing each year and hoping for different outcomes is simply not being business smart. An old adage says that if what you are doing is not working, try something else – try ANYTHING else! Contact us at the MCLMG Consulting Division for a pro bono discussion of how MCLMG consultants can provide almost immedi-ate relief to your PM & BA issues and lackluster performance. Remember, projects done right should be the lifeblood of your organization’s growth and maturation progress. Do not let another quarter go by and just hope that your projects get better – take direct action today and contact us for your initial consultation. Doing nothing will just get you what you are already experiencing – low mission perfor-mance and/or poor return on investment of your organization’s scarce funding resources.

Public or private, the consultant’s at MCLMG Consulting Division can provide you with the valuable information you need to improve your decision making and pro-ject success rates by reducing the uncertainty surrounding those issues that matter to your organization.

The MCLMG Consulting

Division

Alexandria, VA USA

Email: [email protected] Phone: +1.202.239.6929

Welcome to the launch of the Project Post-Gazette’s Consultant’s Corner. This is the space where you will be able to find the offerings and small tips from practicing project management consultants with whom you may find useful in discussing your current project management (PM) or business analysis (BA) issues and/or problems. These consultants have been vetted by the PPG to ensure they are ethical and experienced in their craft. Contact will be between you and them without the PPG involvement or commission. We are offering this as a service to our readers. Please let us know your comments or experiences with these consultants as the PPG has a vendor evaluation board / forum where you can rate or discuss your outcomes with any listing consultant. The PPG will of course provide space for both parties to present their cases and will act as arbitrator if the need arises.

The PPG Staff

Featured Consultant of the Month — MCLMG Consulting Division

mailto:[email protected]



The TRAINING TERRACE

Are your training funds not returning the value you expect? Are you paying extremely outdated per seat rates for training that is neither customized nor oriented towards your problems and issues? Are the training events taught by knowledgeable, but boring

trainers reading or teaching right from the workbook? Are your training funds be-ing drained by travel and other expenses to send your employees to public “one-size-fits-all” seminars?

If you answered yes to any of these questions, your solution is waiting at the MCLMG Education Division through their highly skilled and motivationally capable trainers that believe in the concept that training to be effective must be both stim-ulating as well as enjoyable – otherwise it is simply a waste of time costing your organization twice due to the opportunity cost of sending your employees to training while their own work is left undone. Professional training is so crucial in this economic period given that all organizations to survive must do more with less and this equates to making your current employees more productive. Productivity is directly addressed through effective and focused training and educational activi-ties. MCLMG Education is all about training “how” to do activities correctly, not passing exams or obtaining certifications. We are practitioners not boot camp pro-viders.

We at the MCLMG Education Division can provide your organization with exciting as well as technically competent courses taught by practicing professionals with over 20+ years of both on the job professional experience and training skills. MCLMG trainers are NOT just subject matter experts that could not teach them-selves out of a wet paper bag, but they possess and have demonstrated a compel-ling and polished presentation style that will engages your employees while they learn the new skills and knowledge components they need to succeed. These are not the old “consultants in sweater vests” that many training companies try to pass off to their clients. Out trainers provide the total educational experience and results you need to justify your training budgets and even obtain more resources.


The MCLMG Education

Division

Alexandria, VA USA


Welcome to the launch of the Project Post-Gazette’s Training Terrace. This is the space where you will be able to find the offerings, courses, or seminars on a variety of topics from practicing project management (PM) or business analysis (BA) training entities. These trainers have been vetted by the PPG to ensure they are ethical and experienced in their craft. Con-tact will be between you and them without the PPG involvement or commission. We are offering this as a service to our readers. Please let us know your comments or experiences with these trainers as the PPG has a vendor evaluation board / forum where you can rate or discuss your outcomes with any listing trainer or training company. The PPG will of course provide space for both parties to present their cases and will act as arbitrator if the need arises.

The PPG Staff

Featured Trainer of the Month — MCLMG Education Division




The TRAINING TERRACE (cont)

Do not continue to spend your hard-fought over training budgets on seminars and cours-es that are the same for both you and your competitors. At MCLMG Education we pride

ourselves on using the current educational tools and techniques to provide your organization with a customized learning experience for less than what you are paying for a typical “one-size-for-all” event at outrageous daily rates. We have been providing our clients with world class, individualized training for over 30 years using a very simple, but cost effective pricing structure. Contact us today for your discussion with one of our trainers – not a sales staff, but the trainer that will actually create and deliver your training or educational event. Why wait and con-tinue to pay for less than effective training performance; email or call today and begin seeing the improvement at your next learning event.

The areas of coverage by MCLMG trainers include, but not limited to:

Project management improvement and performance enhancement

Business analysis implementation and improvement

Improved decision making techniques

Decision analysis and information measurement design and modeling

Advanced business case development

Advanced project scheduling design and improvement

Project risk management initialization and execution

Program & portfolio analysis and implementation

PMO creation, implementation and management

Project success rate improvement strategies

Project business sponsor training and strategy creation

Corporate compliance program concepts and setup

Corporate ethics program initialization and training

PPPM (project/program/portfolio) tooling selection and implementation

(Continued from page 71) The MCLMG Education

Division

Alexandria, VA USA


Welcome to the launch of the Project Post-Gazette’s Training Terrace. This is the space where you will be able to find the offerings, courses, or seminars on a variety of topics from practicing project management (PM) or business analysis (BA) training entities. These trainers have been vetted by the PPG to ensure they are ethical and experienced in their craft. Con-tact will be between you and them without the PPG involvement or commission. We are offering this as a service to our readers. Please let us know your comments or experiences with these trainers as the PPG has a vendor evaluation board / forum where you can rate or discuss your outcomes with any listing trainer or training company. The PPG will of course provide space for both parties to present their cases and will act as arbitrator if the need arises.

The PPG Staff

Featured Trainer of the Month — MCLMG Education Division (cont)



agers, business analysts, and

business oriented individuals

each month.

If you have anyone that you

would like to see receives the link

to download the PPG, please get

their permission first (no spam-

The PPG will be making some big

and noticeable changes over the

next few months as our reader-

ship and distribution continue to

rise each issue.

We are now distributing to over

13,000 professional project man-

MCLMG, LLC

P.O. Box 10743

Alexandria, VA 22310 USA

Phone: +1.202.239.6929

E-mail: [email protected]

MCLMG Publishing &

Research

Future Updates & Changes

For the Project Management &

Business Analyst Disciplines

Contact Us


The Project Post-Gazette will be adding a resume bank, classified

ads, and event announcements over the next few months. If you

have need of these services, contact us for more information.

ming), and then forward their

email to our subscriptions depart-

ment for a free link and email to

the current issue.

We are still a no charge subscrip-

tion newspaper—for now.

The Post-Gazette Staff

Comments Welcome issue. Therefore, we have

established several email ad-

dresses that you can use to

accomplish this feedback.

They are:

Letters to the editor use—

letters2editor@

projectgazette.com

As the Project Post-Gazette

continues to publish each is-

sue, and hopefully to improve

its offerings and content, we

must ensure that you, the

readership, has the opportuni-

ty to respond and comment

on the articles, columns, and

editorials published with each

For general comments and

responses to content use —

[email protected]

We will posting a letters to the

editor as well your comments

and our responses each issue,

so please feel free to make your

thoughts and ideas known. We

want you to join us often.

mailto:[email protected]?subject=MCLMG%20Publishing

mailto:[email protected]?subject=Letters%20to%20the%20Editor

mailto:[email protected]?subject=Letters%20to%20the%20Editor

mailto:[email protected]?subject=Comments%20on%20PPG



Case Study Supplement As the Project Post-Gazette continues to grow, expand, and add new content and writers, there

are special items of interest given their impact and application to a number of our readership.

We have the honor of being able to provide you with such an artifact from our frequent and

very well-accepted writer — the MuTo Performance Corporation. The MPC has been providing

the PPG with original and new content concerning their annual project obstacles survey, and

they now have kindly allowed the PPG to print in its entirety their detailed study of a recent

complete project environment that will illustrate all 10 of their identified Project Obstacles and

then align them with their “Five Foundations of Project Success.” We are proud and pleased to

bring you, our readership this very insightful and informative case study and analysis.

The PPG Editorial Staff

The PPG Publisher

“Build the House

from the Top Down!” By

MuTo Performance

Corporation

Case Study Supplement



What follows is an analysis of a project concerning the migration of the Desktop Operating System of over 6,000 users from

Windows XP, to Windows 7 for a MuTo Client. The client in question will remain anonymous. Suffice to say it is in a highly

compliant and regulated industry and has a treasure trove of liquidity as well as mass opportunities for continued growth into

the future.

This analysis will review the beginning, middle and end of the project from its conceptualization through its design and imple-

mentation into its closure in terms of the Top 10 Obstacles to Project Success™, and the Five Foundations of Project Success.

The Top 10 Obstacles are the product of a global survey conducted annually by MuTo Performance Corp. Thousands of pro-

ject professionals respond to the survey and rank the Top 10 Obstacles to Project Success in terms of frequency on their pro-

jects. At the time of the Conceptualization of the project in question, the following were the rankings of the Top 10 Obstacles

to Project Success:

1. Changes to Project Scope (Scope Creep)

2. Resources are Inadequate (Excluding Funding)

3. Insufficient Time to Complete the Project

4. Critical Requirements are Unspecified or Missing

5. Inadequate Project Testing

6. Critical Project Tasks are Delivered Late

7. Key Team Members Lack Adequate Authority

8. The Project Sponsor is Unavailable to Approve Strategic Decisions

9. Insufficient Project Funding Key Team Members Lack Critical Skills

The Five Fundamentals to Project Success™ are necessary to have in place in order to prevent the above obstacles from occur-ring during a project. The Five Fundamentals are:

1. Project Life Cycle PROCESSES that adhere to best practices and are optimal to the organization’s business, understood by

all project team members and adhered to by them.

2. SYSTEMS that automate these Project Life Cycle Processes optimally without added complexities that would make

them onerous, understood by all project team members and used by them.

3. A team of individuals that COMMUNICATE clearly, concisely and always.

4. A team of highly MOTIVATED individuals that adhere to the corporate values are self-driven to achieve the project goals

on time. A team of highly ACCOUNTABLE individuals that carry out their roles and tasks responsibly.

First we will start with the “lay of the land” or the environment. Then we will review the Project Management Environment, the presence of each of the Five Fundamentals to Project Success, and finally each obstacle in its appearance on the project.

The Environment

The client is a public company which is still led by the founders. It is in what is considered an undervalued position on the market and has attracted the attention of speculators, and known raiders. About midway through the project, the Board of Directors of the firm has created a ‘poison pill’ which has as one of its components Spartan-cost cuts, one of which impacted


Build the House from the Top Down!



this project.

Although wealthy and cash-flush, the company finds itself in a position where through market pressures, loss of patents and strategic positioning, it has lost its ‘cash-cow’ products. The nearest new cash-cow will not be seen for a few years.

The company has approximately 6,000 associates, of whom about 20% are consultants. 50% of the associates are in the sales and marketing area, while 40% are in research and the remainder in support capacities.

The company’s Information Technology (IT) department suffers from (a) the lack of standardization, and (b) the lack of project level processes. As a result, most users lack trust in IT efforts and capabilities, but have a strong dependency on the services provided.

The company’s IT department is organized around three primary stove-pipe organizations:

Application support for the Sales Marketing group, Application support for the Research Group, and Application Support for the back-office operations.

There is an independent group that operates Databases, and then of course the overall Infrastructure Group. Each of the Ap-plication Support Groups has the equivalent of a CIO, and operates independently from each other. The Infrastructure group has a CTO, who is beholding to all the CIO as Clientele. The CTO is the Sponsor of this project.

At the beginning of the project, the IT organization reported to a COO who was extremely detached, and all the CIO’s reported to a single overall CIO who was a peer of the CTO. Midway through the project a reorganization of the IT department put the CTO underneath the CIO as a peer to all the departmental CIO. This caused friction within the IT department and was a poten-tial feeding ground for political bacteria throughout the project.

The departmental CIO for the Sales and Research areas both had completely divergent operating cultures. Although both were extremely sensitive to the client needs, the Sales support group is a dynamic ‘fire-man’ culture bent on ends over means, while the Research area while focused on the means races to the end, creating a highly pressured environment. Asso-ciates from both departments express outright dislike for their CIO. Clients of the Sales department have a respect for their CIO and the best of trust factors for their support group out of all the IT departments while clients of the research department show no such respect for their CIO, or their IT department.

In truth both support departments are highly experienced, and very good at what they do. The quality of the clientele within the Sales department is classically that of a social and dynamic group, while the quality of the clientele within the Research department is largely analytical and critical. This may explain the difference in departments.

However, both departments share something in common. Their Clients run their strategic IT decisions. In both cases, when the client says “Jump” the support group says “Yes!” and jumps as high as they can. This produced an inordinate amount of disparate applications in preparation of the migration to Windows 7, which led to non-standardization and an individual ap-proach to the migration instead of a group approach.

The back-office area is plagued by complex and unique applications and much dependency on databases for their efforts. Per capita, this support group has the widest array of applications to support. They include everything from traditional financial applications, to security and manufacturing systems. The clients in this department are not as impulsive as those in the Sales and Research department, but the overall sense is that users at the company believe they are entitled to what they want






when they want it, and IT has always support this negative behavior.

In some respect the lack of governance and financial processes that would ensure a more cooperative partnership between IT and the business are at the root cause of this situation. Neither project portfolio governance, nor a ‘charge-back’ model for IT costs are in place. So, in essence, all requests for business level projects are considered before any necessary IT infrastructur-al projects, sometimes at their expense, and the business does not have a real sense for the total cost of ownership for any requests they make.

In summary, the overall business environment is such that any of the company’s associates in a support position are highly stressed. The constant talk of cost cutting, outsourcing, loss of key-products has raised the level of stress among associates to a high level. They are therefore less willing to raise issues, or complain. They also exhibit more ‘ruling’ behaviors over those that support them, such as IT This adds an exponential amount of stress on the part of IT support personnel, as does the lack of governance or fiscal processes. The one saving grace is the company is a devoted user of a Remedy driven ITIL Process. Without this framework, this project would have been facing TOTAL, not PARTIAL chaos.

The Project Environment

The resulting project manager was the third in a line of three project managers. The first lasted for a period of a few months and left prior to the hiring of a third party expert group for the process of Deploying the new Win7 build. The second joined about that time and left a few weeks after, once the enormity of the task was made clear. The last project manager (the PM) was told at his interview “What’s great is we have no Project Processes or Methodologies. That makes it easy. You can make it up yourself!” Although the words were intended to paint a picture, and not set a direction, they are indicative of the fact that while the company had some very good Operational Processes, steeped in ITIL, it lacked any cohesive project road-map.

Within the Infrastructure team, a fledgling PMO existed headed by a new comer to the company who had Project Experience, which was charged with the creation of a Project Roadmap. By the time the PM’s job was done, the PMO had some basic pro-ject processes in place, for portfolio reporting of status, as well as fiscal responsibilities, and the beginnings of a Project Roadmap that would bind the Application Support Groups together as a best practice.

This project was to be an Infrastructure initiative that relied upon activity from each of the Application Support groups and users as key suppliers eventually. The Research group had its own PMO adding a layer of coordination with supplier re-sources. The Sales group had a thick agenda of its own portfolio of projects and dynamic nature which lent itself to the politi-cal morass. The other groups were not as organized but did have their own portfolio of projects underway. None of them expected to devote much if any resources to what they deemed an Infrastructure project.

To help manage through this, the Infrastructure PMO pulled together a Steering Committee comprised of the CIO’s and their direct reports along with the CTO, engineering leads, client services and support leads as well as the Project PMO. This steer-ing committee met regularly and was the decisive body on the project. In fact this was the ‘oligarchical Sponsor.’ Their deci-sions were largely ratifications of directions decided upon by the direct Sponsor, but almost from the start the lead of the Infrastructure PMO became the delegated Sponsor for the project.

The Sponsorship Decision/Authority matrix came down to the following for the duration of the project:






The supplier relationship evolved overtime on the project and started as largely an Infrastructure only project, with a single outside supplier (3rd Party Deployment Group) which accounted for a large part of the project budget. Eventually the supplier relationship included most of the Operational IT groups within the company, as well as all Users.

The beneficiaries of this project were primarily the users. However it can be said that the compliance nature of the project placed the company in the beneficiary seat. By migrating in time in a highly compliance oriented industry, they avoided com-pliance issues. It is largely regarded as an increase in functionality, thought, rather than a compliance task when migrating operating systems. As such, the users played the traditional role of beneficiaries.

In summary, the Project Environment was virtually non-existent. Mostly fed by the operational ITIL processes and systems in place the project suffered from the lack of urgency caused by an Operational system/process. The fact that the Application Support groups felt they were not responsible for anything to do with the project made accountability an uphill battle. How-ever, in the end the team did come together and accomplish the tasks.

The Presence of the Five Fundamentals of Project Success

Project Life Cycle PROCESSES that adhere to best practices and are optimal to the organization’s business, understood by all project team members and adhered to by them form the backbone of the Five Fundamentals to Project Success. As discussed previously, there were few Project Life Cycle Processes in place in the firm. Most of the processes included the raw ITIL opera-tional methodology for changes to production, rather than the robust Project Lifecycle processes one might expect. This caused many suppliers on the project to not be sure about next steps, and great delays in the responsiveness of suppliers who thought requests were coming ‘out of process.’ Also to a large degree it was noted that many people did not know or under-stand the actual operational processes that needed to be followed, once those were identified. (ie: the Packaging Process, Request for a system, etc.) SYSTEMS that automate these Project Life Cycle Processes optimally without added complexities that would make them onerous, understood by all project team members and used by them. The automation of Project Life Cycle Processes was




Sponsor Decision/Authority

CTO All decisions involving Expenditures, Budgets, Contracts and delays were firstly presented to the CTO. Who in turn needed to get budgetary approvals from the Financial department, and/or the Corpo-rate CIO.

Steering Com-mittee

All decisions involving delays and project approach.

Head of Desktop Engineer-ing

All signoff on 3rd Party Invoices, and Time-sheets.

Infra-structure PMO Lead

First stop for all Project Sponsor decisions. All decisions regarding issue resolutions, and scope creep were mostly accomplished at this level. Any others were escalated to CTO or Steering Committee.



limited to the following;

a. Microsoft Project: Widely used but without a standard for project scheduling. In some instances MS Project is actually

used to attempt to manage the live tasks on a project.

b. Remedy: The ticketing and alert system used to report issues, and followup on Support items within the ITIL system at

the company. All Operational IT groups have access to Remedy and know they must “have a remedy ticket” to get anything done. But not all personnel know how to actually get a remedy ticket into the right hands, or how to followup on those as-signed to them. The organization as a whole is ‘certified’ on the use of Remedy, and it is setup on ITIL principles. However, many users avoid Remedy, or simply use it as a necessary evil. This is evident by the quality of information on Remedy Tick-ets. Typically users must contact each other for detail as a result. PPM: A Project Portfolio management system. This system is used by the PMO’s and all Project Managers in Infrastructure must keep their resource requirements, and time-sheets accurately on it. However, Resource Management is not connected to ‘users’ rather it is connected to roles. As such, there is no reconciliation between the PM, the Resource, and the Resource Manager, unless that PM reaches out and confirms. People at the client are divided into two camps. Associates (actual employees of the firm) and Contingent workers (Contractors.) Contractors benefit from none of the amenities offered to the Associates, but are treated as employees for all other intents and purposes. Both camps tend to have the same access to productivity systems. To further divide the ‘people’ there are Internal Customers, and Providers. These providers tend to be very reactive to the needs of the internal Customers, accepting full responsibility and accountability, even for the customer’s lack there-of.

a. Communication between groups is very segregated. People tend to only communicate with individuals within their team,

or those capable of helping them with their situations/issues. Communication tends to be sporadic as a result, and of an emergency nature. There’s great dependency on the ITIL processes for communication of project items. This causes delay, miscommunication, or lack of communication.

b. Motivation is low, driven mostly by the Provider profile they have adopted, the emergency nature of everything they do,

and the differences between contingent and associate workforce. Accountability is high as most users when they do realize what they have to do, accept the responsibility and carry it out. The problem lies in their understanding and acceptance of that accountability. Many, when faced with what they really must do, reject the idea as new, and potentially “not what they signed up for.”

A rating of this environment of the existence of the Five Fundamentals to Project Success assigned solely from a Project Man-ager’s perspective might be.






Fundamental Rating (1 = rare,

So, in summary the project started in an environment that scored a 3.0 across the board on the preparedness scale. The team’s accountability would eventually save the project, if it was treated as an emergency issue. Those groups within the organization that wanted to stick the project to ‘process’ would have to be worked with, as there was no complete set of pro-cesses to ‘stick to.’

Project Facts at Start:

Project Start: Fiscal 2010-2011: During the last quarter of 2010 a ‘Build’ for Windows 7 was declared ready by the ex-isting engineering lead and the testing process had begun.

Projected End: July 31, 2011 Project Budget: $10,000,000 Demographics: Approximately 6,500 users.

Project Historical Timeline




Fundamental Rating

(1 = rare, 5 = consistent)

%

Project Life-Cycle Processes 2.0 40%

Project Systems 4.0 80%

People 3.0 60%

Communications 3.0 60%

Motivation 2.0 40%

Accountability 4.0 80%

Total 3.0 60%








The Obstacles (At Start, throughout, and at the End.)

Changes to Project Scope (Scope Creep): The project’s scope began as “Migrating all corporate Laptops and Desktops to Windows 7.” This was the scope the original project manager was following. Around January of 2011, this project manager left and a 2nd Project Manager was hired.

By April of 2011, a contract was signed with a 3rd Party to deploy systems. Their scope was to “Migrate all in-house, non-sales, non-lab laptops and desktops with the Corporate Build.” The end of the project was declared at that point to be July 31, 2011. However, by the beginning of July, there was both a new Infrastructural PMO Lead, as well as a new Head of Engineering. At this point, the Infrastructural PMO Lead started the project’s Steering Committee. It was upon this milestone that the 2nd Project Manager left, and a 3rd (of final) project manager was brought on board.

The scope for the project was described going forward to the final Project Manager as “Migrate all in-house, non-sales, non-lab laptops and desktops with the Corporate Build then migrate all the sales Tablets to the Corporate Build.” This was not deemed scope creep, but rather a refinement of the project Scope to define it clearly by the final Project Manager.

In November of 2011, the Sales Group announced that they must be migrated, immediately. It was decided at the steering committee level that the scope creep should be addressed. The CIO of the Sales Group devoted his team to the cause, and assigned an experienced technologist to the job of Project Manager from the Application Develop-ment group perspective. A Junior Project Manager from MüTō was brought in by the Infrastructure team to manage the Sales system Migrations. The effort was estimated to take 45 days, “That’s all the time we really have.” We were told. However, as it turned out, there were two rewrites of the Build, (one to accommodate the Sales force Tablet PC’s which are different than the standard systems, and one to change the build dynamics so that the build would be a reconstruction of an image as opposed to a ‘construction from scratch’.) As it turned out, this scope creep was completed in April of 2012, over three months longer than expected. The cost was contained within the project, and the amount of issues encountered were minimal. The main causes for delay had to do with lack of preparedness of the teams involved, and the false nature of the emergency.

The impact of this delay was a diversion of the critical engineering team from the ‘core-build’ work they were doing. This resulted in Inadequate Project Testing, and Critical Requirements Missing as is noted below.






The only remaining Scope Creep occurred when the New York City area was struck in October 2012, by a Hurricane. The project was forced to shut down for a period of almost three weeks, causing a total five week delay as a result.

Resources are Inadequate (Excluding Funding): Initially the resources committed to the project included only the Infrastructure Desktop Engineering team. Soon after, members of Infrastructure’s Network, and server engineering teams along with their operational counterparts were included. By March of 2011, a contract was signed with a 3rd party resource for the Deployment of all non-sales, non-lab systems by July of 2011. All this was accomplished without a plan for the project, or project design.

As a result, by July of 2011, it was realized that no forward motion was being had. The Engineering team had yet to work on the build, no participation had been garnered from any of the Application Development groups, nor was any expected, and the Deployment Team was burning through their monthly PMO costs without adding value, as none was requested. The head of the Infrastructure PMO called together a steering committee recognizing that there was no centralized point of accountability (ie: holistic sponsorship) for the project.

The MüTō Senior PM began in August of 2011, at the same time, the Desktop Engineering group began to review the previous beta-build, and started to engineer a final build (due to be ready by October.)

A rough design for the project was established, and it was immediately recognized (by the end of August 2011) that the project needed official Application Development Group participation in the form of “Enterprise Application Portfolio Liaisons.” Each AD group devoted a single individual full/part time to work with the Infrastructure Team on (a) identification of Applications that were necessary for their constituencies, and (b) the testing of these Applica-tions.

Once they got started, more work than was expected was sent to the Desktop Engineers for the remedial packaging of applications. A Backlog was soon realized. This was further compounded by not enough resources in the Package Release, and Client Services area to complete UAT, and testing of the resulting packages for production release.

The delays due to inadequate resources moved the initial deployment dates to November 2011.

During the redesign of the deployment process it was recognized that the Project PMO lacked resources sufficient to complete the tasks of Application Preparatory Processes, Issues Management and Scheduling of Users, in a timely manner. These resources were engaged. The original issues manager however needed to be replaced, causing a minimal four day delay in the process, and some confusion later on during the project.

In summary, Resources were lacking at the specific times during the project. The impact of a lack of resources caused Project Delays (such as Sales force, and Deployment Redesign) and Quality of Effort errors requiring the recompletion of deliverables (such as the Build, and Application readiness.)

Insufficient Time to Complete the Project The project was initially calculated to be completed by July 31, 2011. However, in retrospect, the project was divided into three work tracks. The first was the Build Process, which involved the complete engineering, construction, and testing of a Build and Deployment Process along with all necessary Operational Support components. These were thought to be complete, when in fact they were found to be materially missing. The Build Process added approxi-mately eight months to the project timeline.

The second work track involved Application Readiness, which involved the complete testing of all applications using the deployable Build, along with the packaging and testing of all Windows 7 ready packages. Although an initial






round of Application Package Testing occurred prior to July 31, 2011, it was found insufficient. Application Testing started in earnest in August 2011, involving all the Application Development groups, many package remediation efforts were found, and many repackaging attempts were requested. When the Build was reconstructed in early 2012, all the packages had to be retested. This retesting was facilitated by the Desktop Engineering group, and wound up with a number of additional repackaging attempts, and remediation efforts. In essence the Application Readiness Track took over six months to complete.

The final work track involved the Deployment of Windows 7 systems. The initial plan dictated a three month deploy-ment schedule. The initial Deployment occurred in January of 2012, the 2nd Deployment Attempt took from April to June (approximately 2 months), and the final deployment attempt took from August of 2012 to March of 2013 for a total Deployment time of 11 months. Taking into account two holiday seasons, and Hurricane Sandy the deploy-ments were impacted by over 13 weeks of delays (three months) during which the costs of maintaining the deploy-ment team were included. But by far, the scheduling of users cost the most in Deployment Time. Not only was the project unable to reach the estimated 50 user per night projected user deployments, but through the need to individ-ually review and prep every user required so much hand holding that the process took much longer than expected.

In summary, the lack of a proper project planning process caused the majority of the lack of resource issues encoun-tered. Had the Build Process been planned appropriately, its completion would have dictated the next phase’s efforts. Had the Application Readiness process been planned appropriately, its completion would have dictated the actual deployment. Had application portfolios for users been available, the deployment process would not have re-quired individual user handling. This was the single largest culprit of the delay in time to deployment.

Critical Requirements are Unspecified or Missing The fact that the Build needed to be reconstructed, and the Deployment Process needed to be redesigned indicates to large areas of missing requirements. Both of these groupings of missing requirements had an impact on the delay of the project, as well as underlying costs. The redesign of the deployment processes was necessary because of a lack of understanding of user application portfolios which led to too many issues reported during the 2nd Deployment attempt. The reconstruction of the Build, stemmed from an abort of the 1st Deployment attempt.

Inadequate Project Testing The project suffered from inadequate project testing as revealed through the need to reconstruct the build, as well as the redesign of the Deployment Process. Had the build been properly tested, the need for reconstruction of the build would not have been heralded by an aborted deployment attempt. Had the actual state of understanding of User Application Portfolios been revealed early on, proper testing could have occurred on a Departmental Portfolio level, leading to a quicker deployment timeline.

Critical Project Tasks are Delivered Late Most project tasks were delivered on time, however application testing did lag. The amount of time devoted to ap-plication testing was short-sighted given the intensity of the testing required. Many of the remediation efforts re-quired the attention of the support groups, which were under-resourced to provide adequate UAT in time.

Key Team Members Lack Adequate Authority Across the board, the authority levels allowed to project team members tended to be satisfactory, however in some cases it was found that project team members felt they were not ‘authorized’ to carry out their responsibilities, due to the ramifications of doing so. Although this was not rampant, the causes of the few times this did occur was the lack of managerial support for critical decisions. In these cases, decisions were generally requested of management which then freed up the key team members to carry out their responsibilities.






The Project Sponsor is Unavailable to Approve Strategic Decisions Although the Hierarchical Project Sponsorship was in place by the time the project started in earnest in August 2011, the overall impact of the project sponsorship was delayed somewhat because ultimately, the fiscal policies at the Client prevented true ownership of the cost of deployment. For example, if any of the Business Clients wanted tech-nology, they would request it, and the Application Development Groups would have to support the request. Their need to support the request would involve infrastructure teams.

Both the Application Development Groups, and the Infrastructure teams would have to budget for their efforts inde-pendently, as opposed to from an overall project budget owned by the business client. So, ultimately, any work done by the IT teams involved in supporting extraneous requests on this project stemming from the business would never be incurred by the business. This was deemed the primary cause of ‘lack of cooperation’ or ‘lack of urgency’ experi-enced during the scheduling of users in the Deployment Phase of the project. If the business users were fiscally re-sponsible for their application spend (on installation and support) they might adopt a stronger regard for any infor-mation technology requests they make.

Insufficient Project Funding The project wound up spending approximately $1.7 million more than projected (or +17%). The overage emanated largely from excess resources, and time delay. The 3rd Party billed more than $600,000 due to costs associated with delay, reconstruction of the build, and redefining the deployment process. Additional Hardware to accommodate the new deployment process accounted for approximately $100,000. The remainder was largely the excess internal and consulting resources engaged on the project from an Infrastructure engineering, and Operational perspective.

Key Team Members Lack Critical Skills Until the new Desktop Engineering Lead, or the 3rd Party Deployment supplier entered into the project there was no one on the project team that had ever been involved in a mass desktop migration of users. The technical knowledge was satisfactory, and support from vendors although not perfect, was available. However, what was extremely defi-cient was the knowledge base on Applications the businesses used to fulfill their business processes. If a stronger mutual knowledge base existed between the application development teams and their business counterparts many of the issues, and delays, caused by the applications might have been avoided.

Summary

The project encountered everyone of the Top 10 Obstacles to Project Success, and yet was able to finish “On-Time”, and with all its functionality delivered. Over 97% of the population of the company was migrated, leaving behind only a small amount of users. Processes were tweaked within the project, and operational procedures were stretched to their limits. Some were even changed to accommodate project pressures. As a result, the project not only left behind a legacy of “better processes” born under fire, but an amassed inventory of information about the Application Environments that previously had not existed.

The causes of these project obstacles clearly stemmed from the lack of project life-cycle processes, and systems to support them. Although the communication between team members could have been better, and management could have used some motivational training, project team members still acted accountably in the carrying out of their responsibilities. Monday Morning quarterbacks might say that “Planning should have been better.” While true, the environment did not allow for it. As such, the project was executed as best as it could have been. Ultimately, this is a case where the proverbial house was built from the Top Down, on the backs of the project team.



Documents

BOTCHED - Project Post-Gazetteprojectgazette.com/archives/PG_Nov2013.pdf · MuTo Perf 12 Mstr Scheduler 19 urrent Events 27 Risk 29 PPPM 30 ompliance 31 PM Squared 30 ITIL Review