discuss your understanding of "PM YOU" field test one content that was provided for you. 1 page is good enough.

5. PM you … Field Test 1

5.1 Overview

This “field test” examines the following topics with respect to real-world project management:

• Building a good first impression of the Project Manager in the eyes of the performing organization’s senior management, Project Implementation Team, and general staff.

• Obtaining an understanding of the project; what is entailed, and what is the “lay of the land”.

• The project value to the business greatly exceeding the investment in the implementation.

• Adapting a recognized project management methodology and SDLC techniques to the needs of the organization, and to the size & scale of the project to be undertaken.

• Adapting & improving based on the project’s available time duration and budget.

• Getting the project underway based on a laid out plan to move forwards.

• Costing the project for success, not pricing it to a certain death.

• Steps to rescue and recover an ailing project when it gets into trouble.

• How a project can get into trouble, and that differences in understanding of SDLC can lead a project to “failure”.

• Coping with “failure”, self-doubt, work related stress, and making those hard decisions.

• “Failure” is a possibility of fact.

5.2. Introduction

So, what now? … Given that, at your disposal is all of your project management knowledge and training, thus far. … Plus, the copious amounts of your past technical experience that you can always call upon in a pinch. … “Though, will your technical past be a true predictor of your future success as a project manager?”

Well, I guess there is nothing else to do, but put your personalized project management techniques (i.e. “PM you”) to the trials & tribulations of a real-world SDLC project.

5.2.1. The Scenario

Yes, … the interview was a success, and today you start your new job at this smallish company that wants to build their own bespoke product to replace their (externally sourced) aging primary business platform.

Though, the question still remains, hidden in the back of your self-evaluating mind, as the whether your past experiences (both managerial and technical) will be sufficient to lead your assigned project to a “deemed success”, … of being delivered in accordance with:

• Performance Measures – within the agreed [Time] frame and agreed [Cost] budget.

• Customer Satisfaction – with the agreed [Scope] coverage and agreed level of [Quality].

• Effective & Efficient Utilization – of those assigned [People] and allocated [Resources].

• R.I.S.C. Management – given the project’s inherent ˂Risks˃, and given the current situation & prevailing circumstances confronting the project (and the performing organization).

5.2.2. Building That First Impression

Building A Good First Impression, of PM you

Day 1 – Week 1, building that good first impression of PM you:

Dress appropriately for the occasion – dress ready to achieve the business’s objectives of delivering the project successfully while conforming to social norms.

Introductions all round – politely & calmly introduce yourself to those persons you meet in the performing organization; note-padding each person’s name (at least their first name or surname as per cultural norms), where they sit, and what their role is. Especially, those persons connected to the project(s) that you will be responsible for.

Meet The Team – strive to build up the Project Implementation Team members’ initial confidence that you know what you are doing; hence, present a demeanor of confidence in one’s own abilities, but nor arrogantly self-assured nor overconfident.

Mud map the project – kick off with either the project sponsor, senior management, you direct supervisor, and/or the senior implementer(s) to determine what are;

ᴏ the basic details of the project, i.e. the customer’s needs & wants,

ᴏ the basic architectural details of the project’s product / system / application that is to be implemented, i.e. block diagram the major parts, and

ᴏ the basic details of the technologies and processes & procedures underlying the project’s product / system / application to be implemented.

Small talk alignment – start building those friendly working relationships within the performing organization, especially with fellow project managers, and your immediate contacts such as your supervisor and the members of the Project Team.

Discover the true lay of the land – as what was implied during the job interview may not have been the true representation of the project’s current situation & prevailing circumstances confronting the project (and the performing organization).

For this scenario’s project; during that first week of getting to know your way around the performing organization and building up those working relationships that will be essential for the success of the project, you discovered:

(1)The external source of the incumbent system has overtime reduced the depth of the rollout of new features & functionality via the release of periodic product upgrades; hence, this business application has fallen behind in the ever evolving competitive industry that your employer is engaged. … “Let alone, that the product looks & feels like it was built during the last decade, being based on aging technology that is now experiencing compatibility problems with today’s operating systems and web-browsers, so that the platform is one band-aid fix upon another fix”.

(2)Those features & functionality change requests that your employer has submitted (and in some cases, paid for the development of), “recently these haven’t seen the light-of-day” as “it would appear that they are more concerned with the needs of their own domestic market and have forgotten all about us international customers.” … And, “the product lacks the presentation & usability characteristics of modern day web applications”.

(3) Helpdesk & technical support of the incumbent system by the external source has degraded in service turnaround times, now taking several days to weeks delay to respond to those difficult questions. … “Let alone, the significant time zone differences between them and us”.

(4) And, speculation is that, “within a year or two, they are going to terminate that product line to concentrate on their other business. Thus, leaving us out in the cold”.

Hence, the conversational conclusion is that your employer has no other viable options, other than to go it alone and develop their own application; because, the alternative products offerings are either just as aged as the incumbent product of the associated licensing & service agreements would be too costly for your employer’s customers would be too excessive for the local market to accept). … And, that there is only 12 months within which to deliver the first publically usable release of this replacement system.

In additional to the project’s technical situation, you also discovered that, other than industry specific Subject Matter Expertise to call on, there is currently no work-experienced SDLC capabilities within your employer’s organization with which to start building the Project Implementation Team. Hence you, as the project’s manager, are going to have to recruit the project development team from scratch (with the assistance & oversight of your employer’s senior management).

You also discovered that, while “formal project management qualifications and Agile project delivery experience” were advertised as essential to your job’s description, there is not a significant amount of SDLC project management experience within the organization. Hence, you as the “Technical Project Manager”, will have to define the SDLC methodology that will be used by those future additions to this (pending) performing organization.

And, while there has been capital reserves set aside for the project, you have the niggling feeling that there is most probably not a deep-pocketed management reserve with which to call on, if the project happens to get into trouble.

Business Value versus Face Value

While your project may carry a relatively low dollar cost of implementation (i.e “face value”), it could carry a high “business value” to the performing organization as a “keystone” or “linchpin” project.

That is, while the project’s cost of implementation maybe relatively low, the customer organization and/or the performing organization could have the business’s future riding upon the successful outcome of that particular project.

For example; this I.T. systems upgrade project may only have a price tag of $100k - $200k, yet it results in an essential part of the continued & effective operations of the organization’s multi-million dollar business. If this “low budget” project was to perform badly, then the business could find that its operations are gravely affected (and its profitability declines noticeably).

For example; this relatively “low budget” project is the first steppingstone to a larger program of work. Where the customer organization is, in essence, using this project as a litmus-test of the performing organization’s capabilities & competencies. If this “low budget” project was to perform badly and/or fail, then the performing organization could be eliminated from consideration for the larger contract(s), and subsequently find itself scrounging for other work.

For example; this “low budget” compliance project has to be rolled out by a specific date, else the performing organization would lose it certification / license, and subsequently not be able to legally operate in its primary market.

Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management

RULE 40: A project’s worth is not always proportional to its upfront cost of implementation.

5.3. And So, It Begins

5.3.1. Answers To The Opening Questions

Back in [Section 3.3.] it was stated that; “the purpose of the Initiating Phase is to define a potential new project based on the ‘needs & wants’ of the customer, to evaluate the proposed project’s viability, and to then obtain formal signed off approval & authorization to commence the project.”

Additionally, there was listed a sequence of questions that needed to be diligently answered, so as to establish the project’s realistic chances of success.

1. What do THEY (the customer) WANT?

2. What will WE (the implementer) GIVE (to the customer)?

What will WE (the implementer) NOT be GIVING (to the customer)?

1. Approximately HOW LONG do WE (the implementer) EXPECT it to TAKE?

What will it COST US (the implementer) TO GIVE it (to the customer)?

1. What will WE (the implementer) GET IN RETURN (from the customer)?

2. What is AT STAKE FOR US (the implementer)?

The answers to these above questions should provide a good enough understanding of the project’s primary stakeholders “wants”, “needs”, high-level “requirements”, “desired outcomes”, and the “perceived benefits” of conducting the project. These answers would subsequently be recorded in some formalized document to officially accept or reject the undertaking of the project; i.e. the “Project Charter”.

But alas, for this scenario’s project, the Project Charter is considered as a given, because the project “just has to be done”.

A project kick-off meeting is held, for your benefit as the first member of the Project Implementation Team to come on-board. … And, this meeting turns into a couple of weeks of coming together and going through the “Customer Requirements” document. The Customer Requirements document that is a hundred plus pages of bullet-point notes with are a collection of requirements intermixed with ideas (and self-questioning thoughts) shuffled together into quasi-sequential sections, with the insertion of clarification notes and the addition of extra requirements that were thought of during these “explanation” meetings.

Your past technical experience kicks in, and on the meeting room’s large whiteboard you start sketching overview block diagrams of how the various parts of the system seem to fit together (from the perspective of your very limited topic relevant subject matter expertise). The end result being an artwork that is more Picasso-esque than a system engineering drawing; however, your “customer” the project sponsor and the in-house SMEs are impressed with seeing their system represented in an abstract-physical form.

By the conclusion of this meeting you realize that a few factors will influence how this project should be undertaken:

Customer injected “scope creep” of adding extra requirements (as the need arises) is potentially going to be an ongoing issue during the project’s life.

What is being defined is the [Scope] equivalent of a “limousine” when the available [Time] would only be sufficient to produce a “daily driver”. Hence, work towards getting something onto the road in the shortest time, so as to have something functional to use.

Given the [Time] criticality of delivering a usable system as soon as possible, while faced with continued [Scope] clarification and the possible inclusion of additional features & functionality, then a traditional Waterfall system development life cycle of defining the majority (if not all) of the requirements upfront, … prior to the sequential planning then implementation then testing of the deliverables, … is probably not going to work out very well for this particular project.

Hence, you figure that a “rolling wave” Iterative system development life cycle of breaking the project up into major releases of specific features & functionality would be better suited to the situation at hand. However, … …

You have the growing suspicion that the Customer’s Representative is more of a tranditionalist Waterfaller; and as such, will want to define each & every requirement in detail before moving onto the Planning Phase. You also surmise that the Customer’s Representative could have acceptance issues with limiting the requirements definition to those high priority items that need to be known right now, and pushing back on the detailed definition of those lower priority features. Thus, you have a niggling feeling that you are in for a bit of “negotiated compromising” on the [Scope] of the first release (and the subsequent releases).

Rolling Wave Planning is where those activities to be performed in the immediate future are defined & planned out now in detail, and those activities to occur in the not so immediate future are only broadly defined & planned for (and these will be dealt with in more detail later on during the implementation of those earlier parts).

5.3.2. Adapt & Improvise on the Project’s Documentation

For this scenario’s project, you realize that producing all of those documents as per a PMBOK® based SDLC structure, would consume a considerable amount of the project’s available [Time] and allocated [Cost] budget. Hence, you decide to minimalize the documentation tree by hybridizing & amalgamating some documents to have summation information transfer purposes; based on, your past experiences of “what really needs to be known”.

“The sign of a leader is knowing when (and being prepared) to revise & adapt an existing plan | framework to better suit a given situation; when taking into consideration the prevailing circumstances of limited time, money, and people resources that are currently at hand.”

The Project Charter

“The purpose of the Initiating Phase is to define a potential new project based on the ‘needs & wants’ of the customer, to evaluate the proposed project’s viability, and to then obtain formal signed off approval & authorization to commence the project”,

So, … what to put in this Project Charter:

1. Formally presented document … with an obviously titled cover page (with the performing organization’s company branding and identifying the customer organization), table of contents, section headers, and consistent font style & size and text spacing to ease readability. Not just a hurriedly thrown together blank-format document of bullet-point notes; rather, the appearance of a professional document.

2. Identifying name for the project … a name that human-people can easily roll-off the tongue in conversations & discussions. Not just a serialized Project Number nor convoluted acronym which denotes the constituent parts of the outputted product.

3. Table Of Contents … to retain a sense of order and to aid in information discovery.

4. Introduction

ᴏ Background Information … an “executive summary” of the underlying ‘needs & wants’ as to why this project is proposed to exist. Briefly describing what is this proposed project’s purpose, and what are the ‘perceived benefits’ from undertaking this project.

ᴏ Project Goals … a summary of the ‘desired outcomes’ of conducting this project.

ᴏ Measurable & Tangible Objectives … a bullet-point summation of the project’s high-priority high-level [Scope] of deliverables and those hard-pressed constraints on the project’s undertaking, such as; restricted [Cost] budget, unmovable delivery dates [Time], regulatory [Quality] standards compliance, limitations on the assignment of [People] and/or allocation of [Resources].

1. Optionally … Extra Introductory Information that would be beneficial to (be plagiarized by) senior management when putting together a submission to access externally sourced funding, such as via venture capitalists and/or government development grants. That is, the information that would be required to sell the proposed to those potential financial investors, in a 5 minute presentation.

2. Project Constraints … those project parameters, see the theory in [Section 1.2], that are “set in stone” (i.e. FIXED) from the outset of the commencement of the proposed project:

ᴏ [Scope] … those high-level features & functionality that are categorically essential for the project to deliver; else, the delivered system / application / service will not be “fit for use” for “the purpose that was intended” by the end-user customer.

For example; a mobile phone absolutely must be able to make & receive bidirectional telephone calls. In comparison, all other functionality is relatively meaningless without this mandatory capability.

ᴏ [Time] … where there is some unmovable “drop-dead” End Date when this project absolutely must provide its deliverables by, or ELSE !!!

ᴏ [Cost] … where there is some form of financial limitation on this project; either the total funds available, the maximum “burn-rate” spend per month, and/or an assigned “bucket of money” that must be spend for the quarter / half-year / an assigned “bucket of money” that must be spent for the quarter / half-year / financial year (where the project cannot over-spent nor greatly under-spend else risk losing an equivalent portion of the next period’s “bucket of money”).

ᴏ [Quality] … where there is some [Quality] standards / certification that must be abided by for regulatory, statutory, and market expectations for the project deliverables to be deemed acceptable.

ᴏ [People] … the availability / quantity / skill-level of the necessary & available [People], both internal & external to the performing organization, will greatly influence the project’s [Time] & [Scope] that can realistically be delivered.

ᴏ [Resources] … the availability / quantity / grade of the necessary & available [Resources], both internal & external to the performing organization, will greatly influence the project’s [Time] & [Scope] that can realistically be delivered.

1. Additionally, the Priorities of these project constraints may be specified.

2. Project Assumptions … those things that are believed to be true about the project; such as, the availability of key skilled personnel, allocations of equipment & materials, pre-existing technical knowledge, stability of the underlying technologies, meaningful & valid data, the future economy, and environmental conditions … etc.

3. Project Risks … those high-level risks involved with (and with not) undertaking this project; including those inherent risks, management & control risks, and execution vs operational risks. Plus the project’s potential resultant impact outside of the performing organization and/or outside of the customer organization; i.e. to the general public?

4. Project Scope Boundary … those things that will be considered as being within the project’s domain, and possibly listing those things that will be “out-of-scope”.

ᴏ High Level Requirements … a generalized list of those high-level features & functionality that will be handed over to the Customer’s Representatives during and at the end of the project, and possibly at various release points during the project’s life. The receipt & acceptance of such deliverables will form the basis of the Acceptance Criteria for the project.

DO NOT venture into the specifics of the details (no matter how deep), as that is the purpose of the Detailed Specifications. … Just “a single sentence” description sufficient to establish the foundation of the “idea” of each high-level requirement.

1. Intellectual Property Rights … who exactly owns what of those intangible assets of the “knowledge learnt” during the undertaking of the project and as a result of the process of creating the deliverables.

For example; inventions, patents, copyrights, trademarks, designs, source code, circuit layouts, algorithms … the know-how.

Clearly state what are the (IP) Intellectual Property Rights of each party involved with the project; including the customer organization, the performing organization, and any third parties (such as sub-contractors) who will be engaged to participate in the project.

ᴏ Background IP – is that intellectual property which existed prior to the contracted relationship commencing, or is independent of the contract.

ᴏ Foreground IP – is that intellectual property which resulted from or is generated pursuant to the contracted relationship.

1. Project Phases

• Delivery Milestones … a list of the major releases; though, what exactly will be delivered in each specific release should be still open to negotiations (based on the situation & prevailing circumstances closer to the time of delivery). And, noting that a “rolling wave” methodology is being proposed for this scenario’s project.

• Summation Schedule … a Rough Overview Schedule of “a time scale” sufficient to provide a logical guesstimation of the duration and the “level of effort” involved with conducting the project, so as to evaluate the duration viability of the undertaking. However, this is NOT a definitive, down to the last day & hour valuation of the project’s [Time].

• ROM Budget … a Rough Order of Magnitude (ROM) “in the ball-park” intelligent guesstimation (within at least a 20-25% range) of the [Costs] for the [People], [Resources], and [Time] involved. However, this is NOT a definitive, down to the last dollar & cents valuation of the project’s [Cost]; but rather, a logical calculation for the purposes of evaluating the financial viability of conducting the project.

1. Payment Milestones … a breakdown of the proposed partial / progress payments as per the major delivery milestones / releases.

For example; 5% at contract sign-off 5% at completion of the Detailed Specifications & Project Management Plan, 5% at completion of the architectural designs, 35% at completion of the Site Acceptance Tests, 20% at completion of the User Acceptance Tests, 10% at the project closure sign-off, and the remaining 20% at the conclusion of the warranty period. … But wait, that example is for an external customer waterfall project arrangement, whereas this scenario’s project is for an internal customer using “rolling waves”, thus the payment milestones would be based using windows of calendar time (such as monthly, quarterly, half yearly, yearly).

1. Special Conditions such as

• Performance Bond … that needs to be paid by the performing organization as guarantee of their performance.

• Liquidated Damages … involved if the performing organization does not deliver on [Time], and what are the Terms & Conditions related to these liquidated damages.

1. Project Authorization Signature Block … a list of those persons who will approve the undertaking of this project. Also, include each person’s job title, and which organization or business group they represent.

ᴏ Project Sponsor … the person who is paying for this project’s undertaking.

ᴏ Cost Account Authorization … budgetary [Cost] approval for the commitment of [Resources], [People], and [Time].

ᴏ Points of Contact … contact details, and their responsibilities on this project (i.e. Responsibilities Assignment Matrix).

For the scenario’s project, … the Project Charter, ROM summation schedule, ROM project budget, are all accepted by the Customer’s Representative (i.e. your boss).

5.3.3. Adapt & Improvise on the Project’s Duration & Budget

When limited [Cost] budget and/or limited [Time] duration are going to be delimiting factors for the project (i.e. the prominent project constraints) then the [Scope] of the project should be decomposed into re-organizable work packages (i.e. modules of functionality) with an estimated [Time] duration and a price-tag [Cost] associated with each work package. The representatives of the customer organization and the performing organization would then come together and figure-out (i.e. “negotiate”) the most cost-effective combination & arrangement of work packages that will result in the optimal composition of features & functionality; i.e. maximizing the “Return On Investment”. This selected [Scope] would then constitute the “Scope Boundary” for the first milestone release, which would subsequently be delivered as though it were a mini project.

As this first milestone release nears completion (delivery) then the Customer’s Representatives would figure out exactly how much money they have remaining in their budget. Then as previously, the customer representative in consultation with the performing organization would determine the next combination of the remaining work packages that will provide the most cost-effective composition of desired features & functionality to be implemented in the next release.

And, so-on & so-forth for each subsequent release until there is either; not enough of the budget [Cost] remaining, not enough [Time] remaining for another release, or all of the desired [Scope] has been implemented to the satisfaction of the Customer’s Representatives. By which time, the customer may have been able to pull together the necessary budget to fund some of the additional development (possibly loosening their paymaster’s purse strings sufficiently to fund all of the outstanding work). However, firstly they need to see (and play with) tangible proof of the project’s potential for success.

This is similar to a sprint backlog as used for an agile project; though, this would be for converting their waterfall mindset to an iterative implementation, including agile “sprints” of one month durations. See [Figure 85].

5.4. Getting Underway

5.4.1. Overview Schedule as an Attack Plan

In the project’s schedule, you have planned for multiple agile implementation sprints (each of one month’s duration), where each sprint will be targeted at to-be-defined Use Cases, then at the start of the next month the output of that last sprint will be evaluated by the Subject Matter Experts (i.e. “Recognizing” any problems & issues), and then subsequently “Reassessing & Revising” prior to being “Reapplied” in the next sprint.

Due to the significant proportion of the project’s features & functionality which will be dependent on the Graphical User Interface (GUI), you propose that a web designer be brought onto the project as soon as possible, so as to produce wireframe mockups that will help to solidify the understanding & interpretation of the Customer Requirements (and form part of the Detailed Specifications).

Also, due to the previously mentioned quarterly financial limitations, you suggest forgoing the hiring of a senior system engineer / system architect for a while (and to perform this role yourself), until the Customer Requirements have stabilized. Subsequently, after the new year, the plan is for the senior systems engineer / database designer to join the project, then followed by the other implementers.

“Oh, the Project Manager doing non PM work, this is risky, in my opinion.”

DO NOT forget to include holiday breaks, and also to align milestone releases with specified “Drop Dead” delivery dates, such as the End Of Financial Year.

Chart)

For the scenario’s project, the long-term plan is for the members of the Project Implementation Team to remain with the organization for the coming years, so as to develop & deliver the proceeding major releases of the product; i.e. a year and half for the general availability of Release 1.0, then a year later Release 2.0, with a point release every quarter year after Release 1.0 has “gone live” to the paying public.

5.4.2. Costing The Project To Success

In the scenario’s project budget, you calculate the Per Person Costs , the Yearly Staffing Costs, and the Monthly Spend & Total Yearly Cost

The example budget calculations are for a project that is “in-house” | internal to the performing organization, where the Project Steering Committee are only interested in the “bare bones” costs involved with undertaking the project. However, with a project that is for an external customer, then these costings would also include “Safety Margins” and “Profitability Margins”.

Safety Margins are those additional contingencies for cost outlays that potentially (most probably) will be incurred during the life of the project, such as:

• Escalated Costs … are changes in costs | prices due to economic fluctuations over the duration of the project (over each financial year). For example; exchange rates, inflation | Consumer Price Index.

• Project Risk … is a percentage of cost buffering on the “Level Of Effort” involved with conducting the project; i.e. the project may require more ‘actual work to be done’ than was planned for, so have some money set aside to pay for that. For example, an additional 15% to the total cost of the implementers, and 10% for PM – BA – SME – SA.

• Cost Contingency … is an amount set aside to cover potential future expenses, such as providing warranty support and the repair of latent defects; where we are not sure about the actual amounts involved, but based on past experiences then there is an expectation that some costs will probably be incurred, i.e. a “known unknown”.

“Though, some unscrupulous senior managers, after the project’s development has finished, may declare this contingency as revenue come profit; and unfortunately, sometime in the immediate future, when the customer puts in a warranty claim or requires a defect to be rectified then it will be discovered that there is no contingency fund remaining to cover this obligated maintenance period cost.”

Depending on the performing organization’s processes & procedures and based on the contractual agreement with the customer (that all costs are to be itemized), then these Safety Margins would be contained within the Labour Rates Per Hour and the per unit Sell Price for materials & 3rd party services that are incorporated into the project.

That is, external customer is given a “Time & Materials” price, “Fixed Price”, or “Cost Reimbursement” based on these Safety Margins being embedded into the calculation.

ᴏ Time & Materials – the amount to be paid is based on the charge-out rate for each person involved plus the sell-price of materials & 3rd party services used.

ᴏ Fixed Price – the amount to be paid is not going to change from that stated in the quotation, irrespective of whether the actual costs incurred are lesser or greater. A modification being Fixed Price with Economic Price Adjustments.

ᴏ Cost Reimbursement – the amount paid is the costs incurred plus some additional percentage or fixed margin. Could also add Performance Incentives.

Prior to presenting the final costings to the Customer’s Representative, a “responsible” Project Steering Committee should also add to the calculated Project Budget, a “Management Reserve” and a “Profit Margin” so as to obtain an Overall Budget.

• Management Reserve … a “hidden” contingency held back by senior management “just in case” the project encounters an emergency situation that exceeds those other contingencies; such as, a “surprise” issue which falls within the [Scope] boundary of the project and hence does not justify a Baseline Change.

• Profit Margin … (Net Profit) is the difference between what the performing organization is prepared for the project to [Cost], versus the Contract Price / Sale Price that they formally agreed to with the Customer’s Representative; i.e. the measure of the project’s profitability, once all of the project [Costs] “expenses” and the received “revenues” have been accounted for.

While, technically, this is not the correct definition for Profit Margin, see the correct equation below, this makeshift definition is sufficient for now.

Profit Margin = (Revenue – Expense)/Revenue = Net Profit/Revenue

If during the project’s Executing Phase, the Actual Costs of the implementation were to exceed the [Cost Baseline], see [Figure 90], and such excessive Actual Costs were to continue and not converge to conform with the [Cost Baseline] by the completion of the project, then this will eat into the profitability of the project. Potentially, this excess could consume both the Management Reserve and the Profit Margin, so that the project becomes a loss-maker for the performing organization; possibly resulting in a negative cash-flow crisis that could consequently affect the business’s liquidity and solvency.

The project’s budget / cost calculations and the associated Profit Margins (and Management Reserve) is information that the performing organization’s senior management definitely DO NOT want to have known by the Customer’s Representatives. … Let alone, to have this information fall into a competitor’s hands, nor be viewed by nosey employees & contractors.

5.4.3. Pricing The Project To A Certain Death

It is during the project’s Initiating Phase that the performing organization’s Project Steering Committee (i.e. senior management) need to adjust the Profit Margin (and the Management Reserve) so as to “negotiate” an acceptable Contract Price with the Customer’s Representatives; and by so doing, hopefully win the business. Conversely, those Safety Margins (of Escalated Costs, Project Risk, and Cost Contingency) should not be the primary | sole means by which senior management adjust the negotiated Contract Price. … “While leaving the paperwork percentage profit margin, untouched.

“Some senior managers, when needing to win new business so as to achieve set targets for the financial year, will cut into both the Safety Margins and the Level Of Effort hours (as was estimated by the implementers). Thereby, reducing the cost of the work to be done, and coincidently the time allocated to do that work. Though, they will be very hesitant to reduce the project’s scope that is being negotiated with the customer.

Subsequently, the project’s Overall Budget (i.e. Contract Price) will be reduced to a level that will most probably be accepted by the customer, and thereby win this essential new business.

However, all that this ‘cut to the bone’ strategy has done is shift the burden for the project’s profitability onto the Project Manager and the members of the Project Implementation Team, as unrecorded overtime hours that these people will just have to work, if this project is to have any chance of being completed on time and within the stipulated budget.”

The problem with this ‘cut to the bone’ strategy, is that while the “on paper” Level Of Effort [Time] has been reduced so as to decrease the [Cost] and subsequently to “optimize” the Contract Price | Budget, … by not reducing the project’s [Scope] to compensate for these reductions in [Time] & [Cost], then the [People] implementers will still have the same amount of ‘actual work to be done’ as they had previously stated (when they were asked to provide estimates for task durations).

Once the project’s Executing Phase is underway, these [People] implementers will be recording (in the timesheet system) the actual hours that they have worked on the scheduled [Scope] of tasks. This timesheet data and the Percentages Complete for that scheduled work will be used in the Monitoring & Control of [Time], and the Monitoring & Control of [Costs],

And, “lo & behold”, the Earned Value Performance Measures of the Cost Performance Index (CPI) and the Schedule Performance Index (SPI) will both be trending “badly”.

Consequently, senior management will be in a panic, as though, “the sky is falling”.

Yet, in hindsight, if the originally provided estimates for the Level Of Effort hours were used for the [Time] & [Cost] calculations, then the project’s performance thus far would have been “perfectly fine”.

If the “original” Budget At Completion [Cost Baseline] had been used, then the Actual Cost would have progressed “perfectly fine” for the majority of the project’s life to date. However, given that the “adjusted” [Cost Baseline] is being used, then the Actual Cost has been “in trouble” for all of the project’s life to date.

COFFEE BREAK DISCUSSION … Moving dates on an inevitable confrontation

At some point in your project management career, you will be given a project with a specific set of functionality, and you will be asked to put together a schedule and costings. In consultation with your potential implementers and in-house Subject Matter Experts, you will come up with estimates for the Level Of Effort and the task durations involved with undertaking this project. You will diligently prepare a “realistic” project schedule, checking it over with your potential implementers so as to verify that the schedule is feasible as far as they concerned, and then you will calculate the associated project costings. After careful planning as to the [Time], [Cost], [People], and [Resources] required, you then hand this information over to your senior management for their review and for them to include a Management Reserve and Profit Margin.

Then sometime later, you will either be handed back those estimates with reworked numbers, or the resultant numbers will be passed onto the Customer’s Representatives as part of a contractual agreement. Subsequently, when you next see the resultant numbers, you are shocked to discover that there have been noticeable cuts made to the Level Of Effort, so as to produce sizeable reductions in the [Cost] and [Time]. On further investigation, you are astonished to find that the project’s [Scope] has not be reduced accordingly to compensate for the reduction in the Level Of Effort. … At this point, many a project manager will question their senior management about these reductions; and, occasionally there will be some negotiated adjustments made to increase some of these numbers. Though, often these numbers “must stand as is”, and so you (and your Project Implementation Team) will “just have to deal with it”.

While most project managers will yield to their senior management’s right to make such cuts, and just accept their fate of having to make do the best that they can, it is a rare breed of project manager who is prepared to stand their ground and argue the point. However, will such a stance brand that project manager as “not a team player”, being “difficult to deal with”, “problematic”, and/or “unmanageable”.

With the project having been signed off with these ‘cut to the bone’ [Time] & [Cost] baselines in place, the Project Manager and the Project Implementation Team will just have to work (struggle on) within these imposed constraints. Subsequently, to keep the project on track (SPI, CPI, and milestone date wise), the Project Implementation Team (and the Project Manager) have to work unclaimed overtime hours so as to compensate for those cuts to the Level Of Effort and durations; recalling that, the project’s [Scope] has not been reduced, and hence the project’s “actual Level Of Effort” required has also not reduced from those original estimates that were provided by the implementers.

“When Level Of Effort hours and durations are reduced in a budget, spreadsheet, this in no way means that the actual amount of work to be done is also reduced; as these cuts will still have to be redeemed.”

The longer that the project goes one, then the more and more that the project’s actual performance slips away from those baselines, until the reality of facts sinks in to all involved with the project, that these [Time] & [Cost] baselines cannot be achieved without some major changes, specifically to the [Scope] of the deliverables. At which point, the Project Manager (and the Project Implementation Team) bear a disproportionate amount of the blame for the project’s failings. … Even though, they and others know that, “if only those original estimates had been used and not those modified oness, then”. … But alas, who ends up being held accountable??

“Consider a 6 months (26 weeks) project with a 5 people team, at a charge out rate of $100 per hour per person doing a 40 hour week. … 26 x 5 x 100 x 40 = 5200 hours @ $520k project cost. Then senior management agree to a 20% price reduction for the same quantity of scope; but, the Board Of Directors stipulate that charge out rates can’t go below $100 per person per hour. Hence, who makes up for the (5200 – 20%) 1040 hours shortfall ?? The implementers will, 1040hr / 5 people / 26 weeks = 8 hrs extra work per team member per week. … And, then (key) implementers start to resign due to their having to work unacceptable levels of unpaid overtime for extended periods”.

5.5. All Ahead, Full … “Iceberg !!”

With the project now motoring along in the Executing Phase, the project’s monitoring & control KPIs (of CPI & SPI) may start to indicate that the project is getting into some trouble; subsequently, it will be necessary for the Project Manager and the Project Implementation Team to take steps to rescue this project from a pending disaster.

Though sadly, those senior managers who “adjusted” the project’s [Time] & [Cost] so as to “optimize” the project’s negotiated Contract Price, they will often forget that, “if the project had used those original estimates” for the Level Of Effort, “then the project would not be in this trouble”, … according to the implementers, that is.

5.5.1. Project Rescue … Getting Out Of Trouble

An implementer’s solution to problems is often one of, “put your head down, and work harder and longer hours”; whereas, the Project Manager needs to figure out how the Project Team can “work smarter” so as to rescue this project.

Project Rescue

1.. RECOGNIZE … Before anything can be done to resolve the project’s trouble, it must be realized that a problem exists and that the problem is occurring (or is about to occur). That is, the appropriate involved persons must acknowledge & accept that the actual performance / results does not compare well with the expected / planned outcomes.

2.. REASSESS … Before being able to do something “appropriate” to resolve the problem one must; evaluate exactly what happened, determine the cause of the differences between what was expected to have happened and what has actually happened.

3.. REVISE … Now that there is an understanding of what went on and what went wrong then in sequential order; decide whether it is necessary to do something about it, decide whether something has to be done straight away or can it wait for a more opportune moment, decide what exactly has to be done, decide what is the newly expected performance, revise the expected outcomes, and let people know these.

4.. REAPPLY … implement that which was decided to be done.

Schedule Duration Compression

Alas, it is decided that the project’s duration needs to be reduced so as to bring the current delivery dates back into line with the agreed [Time Baseline] milestones. There are a few different techniques that can be used for reducing the delivery duration so as to align with the targeted delivery milestones.

1. Crashing “C.P.R.” – is compressing the schedule’s duration by shortening the time allocated for critical path tasks that directly affect the resultant delivery date, via:

ᴏ paying additional ©ash to the implementers to increase the priority of those tasks that have to be completed sooner, and allowing for additional overtime.

ᴏ adding more (P)eople to work on those tasks that have to be delivered immediately.

ᴏ adding more ®esources or extending the allocated usage of those resources that are vital for the completion of those tasks.

NOTE: The Crashing technique only works for tasks on the critical path; i.e. those tasks (with zero “float”) that if not completed by the task’s individual due-date will directly result in the project / release being delivered later.

The Crashing technique is ineffective when applied to non-critical path tasks. In fact, this technique if applied inappropriately will be detrimental to the project because it will unduly increase [Cost] and its execution can have negative effects on the Project implementation Team’s morale.

(2) Fast Tracking – is compressing the schedule’s duration by performing some tasks in parallel and glossing over those tasks that are not evident in the deliverables.

However, this could potentially reduce [Quality].

NOTE: The Fast Tracking technique requires that the shifted tasks are not sequentially dependent, … and, it works best for tasks associated with the critical path; but it could be used en masse for all tasks in the release.

NOTE: Those “non-evident” parts such as documentation, source code comments, and peer reviews are often the first victims of fast tracking. Followed by a reduction in unit testing, and eventually a reduction in system testing; thus, the project’s inherent [Quality] declines.

The Fast Tracking technique can result in more problems than it was intended to solve, because of the potential that rework will be required on the work that was done, due to:

• The consequential reduction in [Quality], and

• The possibility that the deliverables may not have been built with future re-use in mind, instead being tailored “hard coded” specifically for the targeted milestone. … And, not for the needs of future milestones.

Fast Tracking is inherently risky to the project’s long-term success.

(3) Scope Minimization – “De-Scoping” is compressing the schedule’s duration by officially (and/or unofficially) not including certain features & functionality in the time-sensitive release; i.e. scope re-baselining. Instead these features & functionality shall either; be included in a later release, or be removed completely from the project’s deliverables.

5.5.2. Project Recovery … Redefining The Plan

The sad reality of facts is that, sometimes the project cannot be rescued from its negative predicament (possibly due to the current situation & prevailing circumstances, in combination with the inflexibility induced by those imposed project constraint baselines); consequently, some form of project recovery will have to be undertaken.

Project Recovery

Project Recovery consists of the following steps:

1.. RECOGNIZE … Detect when the project is having difficulty maintaining balance between the project variables and those project constraints. And, involve the senior implementers in the evaluation of this predicament.

2.. ACCEPT … Do not ignore the fact that there is a problem that should be dealt with now, and that it should not be put off until tomorrow or to some later date (or in the worst case to “a head in the sand” never). … “aka, management by avoidance, of dancing around the issue.”

3.. ACKNOWLEDGE … Lay out the true predicament to the relevant primary stakeholders (i.e. the Project Working Group and the Project Steering Committee).

As the Project Manager, DO NOT decide to take it upon yourself to inform the Customer’s Representative of the project’s current negative predicament without having firstly conferred with the members of the Project Steering Committee (and the Project Working Group), as they will need to decide if & when it would be “strategically optimal” to acknowledge the current situation to those involved external parties.

“To be a truly successful project manager then one needs to be PROACTIVE by having prepared in advance competent answers to the following questions. … What have you already done to try to rescue this situation, what do you recommend that we do now to get out of this mess, and what is your Plan-B and Plan-C??”

4.. DON’T PANIC … Back off the level of implementation effort that is currently being applied, “think the whole situation through”, and redeploy efforts to effectively & efficiently “work the problem” to regain stabilized control.

5.. DON’T RUSH … Do not hurriedly throw whatever is available (i.e. Cash, People, Resources, Time) at the problem in an attempt to overwhelm and mitigate the failing project as this most probably won’t be effectively & efficiently targeted at the most cause(s) of the problem(s), and won’t necessarily produce the desired outcome(s).

STOP for a moment and give serious consideration as to whether mounting this project recovery could end up dragging down other projects and potentially sinking the performing organization.

“Bail-outs, fire-fighting and playing catch-up to rescue a failing project can have unforeseen knock-on effects due to the impact of redirecting much needed Cash, People, Resources, and/or Time away from other projects, … and, away from Business As Usual activities.”

GET A GRIP … Identify the cause(s) of the project’s failing, and subsequently make a clear statement about the identified cause(s) of these failings.

Was it due to misunderstandings or misinterpretations of the customer’s needs, wants, concerns, expectations, and perspectives?

Was it due to incomplete requirements, misconstrued requirements, and/or ambiguous specifications?

Was it due to underestimating the scale of the project?

Was it due to unforeseen technical difficulties?

Was it due to the unavailability of the necessary [People] and/or [Resources] when these were planned / expected to participate?

Was it due to poor performance of the Project Implementation Team?

Was it due to poor management by the Project Manager?

Was it due to poor management by the Project Working Group (possibly caused by a lack of coordination & cooperation)?

Was it due to poor management by the Project Steering Committee (possibly caused by a lack of direction, too many changes in direction, over direction)?

Was it due to circumstances beyond the project’s control?

With these “due to” answers in mind, ensure that solutions to these are considered when coming up with the Rescue Plan (and also, for the Recovery Plan).

7.. A RESCUE PLAN … What things can be done right now without having to involve the Customer’s Representative, so as to come up with a reasonable, responsible, and sensible sounding Recovery Plan.

8.. BASELINE CHANGES … To be able to come up with a viable Recovery Plan will necessitate that one or more of the existing project baselines (i.e. project constraints) will have to be changed and possibly changed dramatically. Traditionally, this means that the baselines of [Scope], [Time], and/or [Cost] will have to be reassessed, and subsequently restructured “re-baselined” ; else [Quality], [People], and/or [Resources] will bear a disproportionate amount of the burden of the enacted Recovery Plan, yet still ˂Risk˃ project failure.

It must be accepted that those existing baselines are now unrealistic to achieve; because, to insist on the conformance with all of those old project constraints [baselines] is a continuation of those ingredients that already got the project into trouble. … “which is a recipe for disaster.”

Are there any self-imposed restrictions on the performing organization, such as:

What [Time] remains available to complete the project?

What [Cost] budget remains available to complete the project?

What [People] remain available to complete the project?

What [Resources] remain available to complete the project?

Are there any restrictions mandated by the customer organization, such as:

What [Scope] is “a must have”, and what is the priority order of that [Scope] which remains to be done?

What [Time] must the project deliverables definitely be provided by or ELSE?

What [Cost] budget must be stayed under to remain financially viable?

What [Quality] acceptance criteria must be satisfied in order for the deliverables and associated artefacts to be accepted?

What [People] will still be available to undertake the remainder of the project? Additionally, what skilled [People] will be required to implement that [Scope] which is selected to be done?

What [Resources] will still be available for the remainder of the project? Additionally, what quantities & grade of [Resources] will be required to implement that [Scope] which is selected to be done?

VIABILITY … Based on the information collected so far, answer these questions;

Can this project still be successfully completed?

Can this project still be considered as a worthwhile endeavor?

Does undertaking this project still make sense?

Given the answers to those questions, then should the recommendations presented to the Project Steering Committee to pass judgement on, be;

1. proceed with the project as it currently is,

2. revise the project’s baselines,

3. recover only a portion of the project,

4. restart the project as a “do over”, OR

5. terminate the project henceforth?

10.. AGREE THE TERMS … The Project Steering Committee (in consultation with the Project Working Group) has to decide what is the best strategic options for the Performing Organization; then, to sit down with the Customer’s Representatives to work out and agree on the details of the “Terms Of Action” (i.e. what conceptually is to be done), or to come to an amicable resolution on how to terminate the project (or that portion of the project that is no longer viable).

11.. A REALISTIC PLAN … If it is agreed by both the Project Steering Committee and the customer representative(s) that the project should be recovered then, internal to the performing organization answer the following questions:

What [Scope] can realistically be included?

What is the priority for implementing this selected [Scope]?

What portions of the existing implementation can be used?

What portions of the project’s old planning can be reused?

Redo the project’s schedule to determine realistic [Times] and to obtain revised milestone dates. … Revise this schedule based on the re-allocation of available [People] & [Resources]. … Determine realistic [Costs] due to these revisions.

Beware of the risk of recutting estimates too low to minimize the [Costs], and thereby risk not achieving deliverables a second or subsequent time.

DO NOT forgo (necessary) documentation and/or testing due to the need to speed up the project, as this will only result in future failings of the project (especially during acceptance testing and the receipt of the deliverables).

12.. NEGOTIATE … The internally produced & approved Project Recovery Plan has to be presented as a proposed plan to the customer organization’s representatives, then negotiated (“compromise) with both sides on what they “can and can’t do without”.

13.. REVISE THE PLAN … Based on the outcome of those negotiations, then the Project Recovery Plan will need to be reworked, internally reviewed & approved, and then re-presented to the Customer’s Representative for another round of negotiations.

Be aware that the Customer’s Representative(s) may try to retain more of those pre-existing project baselines than was agreed to during those discussions of the “Terms Of Action”.

14.. REACH AN AGREEMENT … With both sides now agreed that the negotiations are completed, then the Project Recovery Plan (aka “Baseline Change Request”) will need to be signed off to signify the approval & authorization of the revised baselines. And, hence supersede (invalidate) any pre-existing baselines prior to this new agreement.

The project could get itself into another troubled situation if some of the stakeholders are still working to the previous (old) baselines while others are working to the new & approved set of baselines.

Hence, the (new) approved baselines for the project must be made known (and enforced) to all of the project’s stakeholders.

WHAT NOW … With the signed off revised plans in hand, there should be a mini kick-off meeting or stand-up meeting held with the Project Implementation Team and the Project Working Group (and if need be with the Project Steering Committee) to inform them of; the project’s change of direction, what are the new baselines, and how these changes will affect them.

GET TO IT … The Project Implementation Team should now recommence the Executing Phase in earnest, with respect to the “new & approved” baselines.

Watch out for project stakeholders who try to get “scrapped” Scope components reintroduced after the Project Recovery Plan (and Baseline Change Request) has been signed off & authorized.

17.. BE VIGILANT … Continuously monitor the project for the reoccurrence of those causes that derailed the project previously, as these problems may arise again.

Which brings us to addendum to “Adaptive & Proactive” SDLC Project Management.

RULE 6C: Just because you fixed up after a BAD thing doesn’t mean that BAD things can’t happen anymore.

5.5.3. The Scenario … Failure To Gain Altitude

For this scenario’s project, the Project Charter has been approved (though with the [Cost] budget and [People] allocation noticeably reduced from that originally planned), the supporting computing infrastructure has been put in place, the planning & design application software has been acquired, and (via your personal networking contacts) the GUI designer has been hired to start mocking up wireframes of the (stabilized) Customer Requirements. …. And, you have even sounded out some previous work colleagues about their potential future availability to work on this project.

The Customer’s Representative (i.e. your boss) still insists on holding almost-daily meetings to define all of the front-end requirements in detail, even though some of this functionality is for later releases. Thus covering in depth the requirements for that part of the system which they (as the SMEs) understand very well, being how the user interface should look & feel and how it should operate from the end-user’s perspective. … … However, they show little interest in the definition of the system which would underlay that user interface functionality.

With the continuation of these daily gatherings to refine the Customer Requirements (with the addition of even more notes), you draw up a breakdown structure of the various constituent modules of the intended system and map out how these bits inter-relate (i.e. an overview starting point for a Work Breakdown Structure – WBS, and software architecture), and you sort the growing mountain of requirements into a spreadsheet of worksheets that correspond to each of those modules (i.e. forming the beginnings of a Requirements Traceability Matrix – RTM).

Though at present, you are functioning more as a business analyst & part-time systems architect (rather than as a project manager) as you bullet point the requirements, sort these points into the various worksheets which correspond to the numerous work packages / modules, and draft an overview module breakdown diagram (which is starting to look like a high-level Software Object Tree or primitive database schema), plus some initial system architecture designs.

These are long days, but satisfactory progress seems to be getting made; as the plan to bring on that senior systems engineer at the start of the new year (followed by the rest of the implementers in the following months) looks likely to happen.

The first of the GUI mockups start being presented to the SME-Customer (i.e. your boss), with the subsequent updates following the review meetings, where more “clarification” notes are added to the growing list of requirements. Though most importantly, your customer appears to be happy with the work presented thus far, as they repeatedly state how this product betters all of its competitors with its feature set.

Then you are sidelined for a week while you put together the documentation for this project to apply for a government development grant. … And, all the while, the requirements “clarification” meetings continue on a regular basis. Subsequently, you haven’t got the available work-hours to completely fulfil your daily combined duties as business analyst – systems architect | engineer – project manager. Thus, you are left in a state of perpetual catch up; but, (especially when you were an implementer) and work harder & longer hours. … Your spouse and child at home will (have to) understand this, as they have always done in the past.

However,as more and more of the intended system is defined, you (and your GUI designer) start to perceive the project as the equivalent of an iceberg, with a lot more beneath the surface than was initially perceived.

Then, … a few weeks out from the first all-in progress & presentation review meeting, you are shocked to discover that there has been a disconnection in perspective of what are the deliverables for that target date. As per the overview schedule, you had planned to present only the wireframe mockups for Release 1; however, your customer (i.e. your boss) is expecting wireframe mockups for the entire system including those future releases), even though some sections are yet to be defined by the SMEs.

You explain your differences in expectations, but are only given a few days to get back to them on whether it can all be done by then. … And in passing, a Sword of Damocles, comment is made that, “if all of these mockups can’t be delivered by then, well, we’ll have to consider cancelling this project, or outsourcing it overseas”.

5.6. Coping With … “Failure”

5.6.1. Self-Doubt and Questioning Why

For the scenario’s project, you as the Project Manager have just been “kicked in the guts” as it has been revealed that your project’s progress has not met with senior management’s (and the customer’s) expectations. Even though, you and your team member(s) have been working long hours producing the deliverables; while having to deal with the continuous “clarification” of the requirements.

Other than feeling knocked backwards by such news, any(non-narcissistic) project manager will start doubting them self and questioning their own abilities; especially if they have followed a prescribed project management methodology accordingly, and they have done what (they believed that) they were supposed to do.

Question: Did you really know what this primary stakeholder was expecting?

Did you really keep this primary stakeholder informed of progress?

Did you really provide this primary stakeholder with what they needed to know, by

when they needed to know, in a form that they could use?

Did you make sure things were done by when you told this primary stakeholder

that these things would be done?

Or, did you just assume that they knew this stuff; given how tightly the customer

has been involved with the project (on an almost daily basis), as though they were a

member of the Project Implementation Team.

While questioning yourself and doubting your abilities (and potentially that of your team member(s), there is something else to realize. … Analogously, the first delivery milestone is the equivalent of the first game in a sporting championship year.

Unless the project has only one or very few progress marker milestones, then there should still be sufficient opportunities to turn things around; provided that, these selected milestones are close enough together to provide real benefit as performance feedback points.

Alternatively, the project constraint baselines could be so tightly restrained that there is absolutely no leeway if & when things go the slightest bit wrong. Hence, it is not better that the project fail now during the early phases of its life; because, with so tight baselines it was inevitable that the project would eventually run out of maneuvering room. Given that, with any project of a length greater than a few months, then the project situation & prevailing circumstances of the performing organization (and customer organization) will change, … and, sometimes these changes will be a significant order.

Though, if as (captain) coach of this team, you’re going to “get the boot” after only the first game of the season, then in all honesty, things were set from the start to eventually fail.

5.6.2. Differences In Understanding Of SDLC

Alas for this scenario’s project, you realize that your customer does not understand (or is not accepting of) the concept of implementing the project via the planned rolling waves of Agile’s iterative releases; but rather, they see the project from a Waterfaller perspective of having to define all of the requirements (in detail) at the beginning.

Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management.

RULE 41: Differences in understanding of the underlying principles of the SDLC methodology being used will derail a project.

5.6.3. Work Related Stress

The insomniac ticking, on the wall, indicates that it’s ten past four. It is as dark outside, as it was a few hours ago, when you awoke in a pool of your own sweat.

Was that a “panic attack” (aka an anxiety attack), potentially caused by chronic work related stress of being faced with the hard decisions of saying that, “it can’t be done” when knowing that to say so could potentially be the end-of-the road for you and possibly the members of your project team; versus saying, “it can be done” when under those current [Baseline] constraints the project will most probably end as a massive failure.

“Personally, it is better to say that, ‘it will be difficult to achieve, but these are the things I will do to make it work.”

Yet, no matter how the Project Manager tries to balance those triple constraints of [Scope] vs [Time] vs [Cost], it just doesn’t work out; given that the duration is too short, the budget is too small, for the requirements that keep growing.

Different project managers (as well as implementers who are faced with impossible delivery workloads) may react negatively to work related stress in various ways:

Looking for a solution at the bottom of a whisky glass, while cigarette butts smoulder in a coffee cup ashtray.

Secretly sobbing in the car park, not knowing what to do, nor whom to turn to.

Throwing the job in, even though there is nowhere else lined-up to go.

And sadly, but true, committing suicide, because it all must have got too much for them to bear any longer.

Now, these reactions may seem extreme; but, shockingly these are a collection from study of past experiences.

Though, these extreme reactions are not caused solely due to work related stress; but also in part due to one’s own home life situation and personal circumstances.

“Why is accepting (and stating) the facts that it can’t be done as was planned, considered as a ‘failure’ ?? The actual failure would be in lying that it can be done, when you honestly know that it can’t be done that way. It is better to explain the difficulties, explain the proposed approach, document the issues (including names & dates of the decision makers), and accept stretched targets. … … If anyone calls ‘failure’ when the project slips, then refer them back to the amended targets and the documented issues. … … The real failures are those people who believe that they can make impossible things happen by simply saying, “just do it!!”

Why Do People React To “Failure” In Different Ways

People will react to what they perceive as “failure” in different ways, based on their:

• Self-Expectation … Deep down each person has a (private semi-realistic) idea of what their performance should have been able to achieve; and, if the outcome does not match the expectation then this can result in feelings of self-doubt, inadequacy, and/or depression.

• Return On Investment … With all endeavours where time & effort is required to be spent (such as continual overtime work to meet stringent deadlines), you will have to give up partaking in something else or at least reduce your interests in other things for the interim. When the outcome from that endeavour does not balance with what has been surrendered, then it is only natural to question whether it was all worth it, and even to become angry with the party(s) who put them in that situation.

• What else is riding on the outcome … If the successful outcome of the endeavour is a determining factor as to whether a person obtains a much need payment, and/or an inflation-matching pay rise, or just having a job, then difficulties could arrive if this is not forthcoming. Hence, failure could have noticeable financial impacts on that person, and subsequently negative consequences to their standard of living.

• Work versus Home Life Balance … Everyone has to balance his or her work life versus home life, and weigh up which is more important to him or her (at that particular point in their live). It may seem essential to the performing organization that the project has to be completed by a specific deadline, but is it personally as important to them when compared to what outside of work could be lost or be execrably damaged by doing so.

In addition, everyone does not live and work in isolation; what is happening in their personal home life can and will eventually affect their work life, and vice versa. If the situation happens to be bad at home then this can affect their emotional state at work. Similarly, a bad work life can exert pressure on their home life, which eventually result in an unpleasant death-spiral of misery at home and at work, where something will finally have to give (potentially, depressingly so).

Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management.

RULE 42: Everyone has two parts to their life, being work and home. … As long as one of these is okay, then eventually the other will come good, and you’ll end up with a happy worker. But, if both work and home are not okay, then you will have a constantly unhappy worker.

RULE 42A: A constantly unhappy worker will contagiously make those around them unhappy too.

• I did all and more than what was expected & required of me … How do they feel & react when they believe that their consistent performance should have been sufficient to achieve the objectives, yet factors beyond their control wrecked their chances.

“And, now you’re putting the blame for the failure on, me !!”

• Cultural, ethnic, and community background … Today’s workplace is a multicultural environment with peoples from diverse cultural, ethnic, and community backgrounds; and, each of these groups will have a slightly different perspective on what differentiates “A Winner” from “A Loser”, what it means “to win” and “to lose”, and where the consideration (or opinion) that one is a “failure” is a “loss of face”.

• Their personality traits … Everyone reacts differently “to failure”, more specifically towards criticism for having “failed”, and to the pressures of finding a resolution that is satisfactory to the person(s) who are stacking on the “negative criticism”.

At the most basic level, all humans are programmed with a “fight or flight” instinct; but what happens when (physically) fighting is not a social | political option, and when there seems to be nowhere else to run? Alas, the stress builds up until something has to give; consequently, a conscious or subconscious “panic attack” can occur. … And, making resolute decisions during such an anxiety attack or straight afterwards (more often than not) does not result in the best long-term decisions.

Strategies For Dealing With Work Related Stress

The following are commonly suggested ways of handling work related stress:

Have a balanced diet and not burying your sorrows in unhealthy “comfort” junk foods.

Doing regular exercise, sweating out of some of that stress, breathe in some fresh air.

Getting a good night’s sleep, and that means, packing it in early and going to bed.

Talking the situation over with someone who will listen.

Social Participation of doing something (non-work related) with other people, and not isolating yourself away (to battle on with the problem alone).

Disconnecting form work and routinely doing something you like to do (irrespective of how age inappropriate or juvenile it may seem to others). … “All work and no play makes jack a, stressed out sack of bones”.

Putting together a short prioritized to-do-list of things that must be done, where lower priority to-do-list items can wait for tomorrow’s list. … Taking it one day at a time; or rather, one to-do-list item at a time.

Doing only one thing at a time, because multi-tasking of trying to get multiple things done at the same time ends up with nothing being done satisfactory; but, don’t do each thing to perfection, because good-enough is probably sufficient to move on the next thing to be done.

Delegate, Delay, Delete … that is, don’t do everything by yourself, allow / ask others to help. If it doesn’t need to be done right now (with little to no negative consequences) then leave it to another time. If it can wait to another time then does it really need to be done all?

Look for solutions to the current situation at hand, and not mentally stockpiling more issues & problems that could eventuate.

And, as the great philosopher, Ferris Bueller once said, “Life moves pretty fast; if you don’t stop and look around once in a while, you could miss it.”

Project Management Dealing With Work Related Stress

From a project management perspective, strategies for handling stress would include:

Discussing the project’s difficulties over with your immediate supervisor (i.e. the Program Manager); trying to get them to understand the current situation & prevailing circumstances which make the project currently viable (from your perspective), and strive to have them assist you in requesting (possibly arguing for) the project baselines to be adjusted accordingly. … Unfortunately, sometimes there is no intermediary between the Project Manager and the Customer’s Representative (as per the scenario project’s case), and hence such a discussion may fall on death ears.

“Though, being new to an organization, you probably won’t realize what kind of boss you will be working for until you are heavily involved with the project. By which time you may find that they are volatile, autocratic, narcissistic, and/or have a psychopathic personality where they have a ‘just do it’ attitude to making impossible things happen, without and consideration to compromising.”

If support from management above is evidently not forthcoming, then seeking advice / input from your peer project managers (who are at the same performing organization) could result in the consideration of alternative solutions; such as, proposing the reallocation of [People] and [Resources] for a short period of [Time].

“Though, don’t go robbing Peter to pay Paul, as this will fail them all.”

Alternatively, seeking the advice of workmates / friends in similar industries and workplaces, even consider calling upon former mentors who may suggest alternative solutions that you may not have considered (or given real consideration to).

Talking it over with your spouse / partner, because any hastily made decision about work could have a direct (negative) effect on them (your family).

Which brings us to an addendum to “Adaptive & Proactive” SDLC Project Management.

RULE 42B: When in trouble, talk to someone about it; do not bottle it up inside, as there could be disastrous consequences when the pressure eventually bursts.

However, after all of this talking it over and contemplating (the what, when, where, and so forth), the resolution will come down to variations on only a few options.

1. Battle on through with things exactly as these currently are.

2. Throw it in, and walk away. … Or, at least devise a personal exit strategy.

3. Accept the facts that it can’t be done as was originally planned, and propose alternative modifications to The Plan, i.e. how to re-baseline the project. … And, then work off of senior management’s response.

Whatever you do, you need to do something; as to continue on with such chronic work related stress of being constantly on edge is not good for one’s health, nor for those in close proximity, nor for one’s work & personal relationships.

Making The Hard Decisions

For all of that stress that has built up, it is simply a matter of fact, that eventually a decision will have to be made; whether that decision be made voluntarily or forced.

Something will have to be decided; hence, the Project Manager could choose to:

1. Say that “it can be done” as was planned, and strive to bulldoze on through. However, the members of the Project Implementation Team will in due course validate that decision; because, if the implementers are faced with impossible delivery workloads then they may individually decide to “throw it in and walk away”, or give up trying.

2. The Project Manager could decide to “cut & run”; but, what will this do to that project manager’s reputation? … And, here is an ethical conundrum; decide to stay and work on a project which you have little to no faith that it can be successfully completed as was planned, or to abandon your fellow team mates to a fate which you have probably just pushed to the edge with your departure.

“Though, walking away is often the best response to illogical commands of ‘just do it’ for something which is not possible to achieve.”

1. The Project Manager could admit to the reality that the project can’t be done as was originally planned, and hence state that modifications need to be made to The Plan, i.e. re-baselining the project. Then, let senior management decide how to respond to the project’s actual situation. … Senior management could either; initiate Project Recovery, or they could demand that “it just be done, OR ELSE”.

“I’m in the same boat. I gave them a realistic estimate to complete the project and was told that this was unacceptable. So they tried to enforce staff ramp down and the project slipped. Then the client complained, so we tried to rehire the staff, as the project slipped even more, and the costs continued to mount up. We are now 3 months later than the original estimated dates and budget. But, the guys who sold the deal and signed off on the contract are still employed.”

Such threats against the Project Team is a double-ended knife in that; by getting rid of the Project Manager and/or members of the Project Team, then this will result in greatly reducing the project’s current progress & stability, and disrupting the motivation & morale of those who remain on the Project Team. Alternatively, the members of the Project Team could privately decide to ride-it-out, and look externally for other employment opportunities (and then leave on their own terms).

“Yep, I’ve witnessed a project get screwed because another long-term senior engineer resigned. Subsequently, senior management were in a panic, trying to encourage that particular engineer to stay (at least to the end of the project) while privately shoring up those other remaining engineers. But, anyone who was paying attention would have realized that this situation had been in the making for some time, given the implementers dissatisfaction with the heavy burden of their workload due to them having to make up for all of those on-paper hours that were cut from the project when the Contracted Price was signed off.”

5.7. “Failure” a Possibility of Fact

Well, the scenario’s project has not worked out exactly as was planned. After the Project manager officially stated that all of those requested deliverables could not be produced by the stipulated date, the senior management (aka the customer | your boss) made the decision to continue on with the project as a waterfall arrangement, with all of the GUI mockups to be produced before moving forwards with any of the implementation. Hence;

“Thank you, for all of your efforts on the project; but, I’ve decided that it would be better if we got in a couple more GUI designers, in your place.” Henceforth, your contract as project manager has been discontinued.

Alternatively, you tender your resignation; because you have already found new employment elsewhere.

Alternatively, “come hell or high water” you decide to push on with this project, even though it has been reorganized from (what you believe is the best solution of a) rolling wave to a waterfall arrangement.

…

Yes, that last project was not the success that you (and they) had planned it to be. … And, here is an undeniable reality of fact, … not every project will be a success.

Not every project that you will manage (let alone work on) will be deemed “a success”; projects will fail due to various reasons, given the current situation & prevailing circumstances, as well as the flexibility & inflexibility of the project constraints [Baselines].

Just as, a sporting team is not going to win the championship year after year, let alone with every game in a single season.

5.7.1. “Failure” Is Opinionated

Every once and a while, you as a project manager will have a losing project; i.e. a project that was considered “a failure”, because it did not satisfy the project’s primary stakeholders (and especially the project sponsors) expectation and/or stipulation on the project’s [Baselines].

That being, the project, as per the theory did not satisfy some or all of the following:

1. SCOPE … did the project produce the expected results and does the resultant deliverables contain the agreed features & functionality?

2. TIME … was the project’s output delivered to the customer (i.e. the persons requesting the product, service, or goods) when it was agreed to be delivered? That is, did the project deliver to its milestone dates?

3. COST … did the cost of the project not exceed the budget that was allocated for undertaking the project? That is, was the project a profitable endeavor?

4. QUALITY … did the resultant deliverables meet the agreed Acceptance Criteria?

Additionally,

1. PEOPLE … did the project effectively & efficiently utilize those persons that were assigned to do work on the project?

2. RESOURCES … did the project effectively & efficiently utilize those material & services resources that were allocated to be used by the project?

Recalling that, the determination of whether a project is deemed a Success | Failure is based entirely on the expectations & perspectives of the people involved with the project; i.e. “FAILURE IS OPINIONATED”.

5.7.2. Project Autopsy

In this scenario project’s case, the project did not succeed due to a combination of the following factors:

The [Scope] of the requirements were continually evolving | in flux.

The [Cost] budget was insufficient for the scale of the project that was to be undertaken.

The limited [Cost] budget restrained the allocation of [People] being insufficient for the amount of work to be done.

The mandated delivery [Time] milestone date being too short a duration given the [Scope] of work to be delivered by the limited number of [People] doing the work on the project.

Additionally,

Differences in understanding of how best to implement the project given those above considerations, hence a rolling wave structure versus a waterfall arrangement.

Misunderstandings and misinterpretations between the project sponsor (aka project steering committee – project SME – the boss), the Project Manager (aka business analyst – system architect), and the Project Implementation Team.

Which brings us to the next rule of “Adaptive & Proactive” SDLC Project Management

RULE 43: Irrespective of the best laid plans, failure is always a possibility.

RULE 43A: Project management is about minimizing the possibilities for failure; however, project management cannot always guarantee success.

COFFEE BREAK DISCUSSION … Even a successful project can end in failure.

Projects are destined to eventually fail due to the misalignment of the project variables and project constraints; such as, the agreed [Scope] exceeding the capacity of the allotted [Time] duration, and/or the allocated [Cost] budget, and/or the assignment of [People] & [Resources], and/or the mandated [Quality] standards, … and, other such combinations of project variables and constraints.

However, sometimes, a perfectly fine project that was clearly on the road to success, also failed due to situations and prevailing circumstances that were beyond the control of the Project Manager and the Project Implementation Team (and for that matter, not the Project Working Group, and not even the Project Steering Committee).

Project failures have been due to such things as:

All or the majority of the members of the Project Team had to be hurriedly reassigned to work on a strategically higher priority project; irrespective of the fact that their own project was oh-so close to release or a successful finish.

An economic crisis hit the parent organization (and thereby the performing organization), consequently a hasty downsizing in the organization’s operating costs had to occur, and subsequently “the baby was thrown out with the bathwater” as all or the majority of the members of the Project Team had to be made-redundant.

The parent organization purchases or was purchased by another organization, and during the subsequent analysis of the overlap between these businesses it was found that the project is very similar to an existing project / product in the combined organization, and hence the project was terminated due to being surplus.

The Sales Department | Business Development Group misread the market, and subsequently what is being developed is not what the market is actually wanting.

Senior management were involved with some underhanded business practices and on discovery by either the parent organization (or worse the customer organization) the contract was hastily terminated, and hence the project ended unceremoniously.