Skip to main content

Tag: Agile

Market Turmoil 2008; Two Lessons Learned

I am writing this entry as the US government is feverishly working on measures to prevent the financial system from a collapse. The very same pundits who were yesterday busy predicting the brightest of futures and unstoppable growth of the market, act today as if they have “known all along” and readily dispense new prophecies.
Not a day goes by without another analysis of this mother of all roller coasters and I bet even Playboy will publish one at some point. Not to be outdone, I want to share with you two lessons, which I took away from it.

Test your models

You may or may not know this, but financial institutions employ scores of exceptionally bright people with advanced degrees in math and physics to develop and maintain various financial models. Among those are models for financial risk management, which are very similar if not the same across the financial world and employ a well-developed mathematical apparatus.

These people, referred to as “quants”, are very well compensated. I mean, half a million a year is not uncommon. The question that naturally comes to mind is, ok, with all this mental firepower and the gaggle of people whose very job was to watch the risks, how come we are where we are?

There are a few reasons at play here, including the business and communication skills of the “quants”, the likelihood of their being listened to, and the challenges of admitting mistakes. But the key problem, I think, is that we tend to fall in love with our models.

Whatever model we subscribe to in our decision making, our work, our lives, we must take a stance that models are just approximation of the reality and not the reality itself. In this particular example, people and organizations became married to their risk management models, they held the assumptions that these models are based on, as paramount axioms; they did not allow for the fact that they may be deficient. This is not the first time it has happened, of course, and the spectacular crash of the Long Term Capital Management in 1998 (about $4 billion lost) is still fresh on the minds of many today.

If you are a project management professional, watch out for falling in love with the methodology and approaching each project with a predetermined approach. I often hear consultants say that they have a methodology for something before they know what the problem is and I want to tell their prospect – run for cover!

Be Suspicious of “Star” Performance

As many other industries, the world of finance is prone to this silly admiration of star performance where the person making money is placed above usual controls, and is so high on the pedestal that if he crashes, it will get awfully messy. It is not like the world of finance does not know what often happens. There is Nick Leeson of Barings Bank. Barings is no longer with us, courtesy of Mr. Leesons stardom status, which allowed him to take uncontrolled risks. Close to one billion dollars later, the 200-year-old bank was gone.

There is Robert Citron, a former treasurer of Orange County (I find the play of names rather amusing), who used derivatives to speculate on interest rates. He was successful for a while, so much so that his opponents, who pointed out the risky nature of his undertakings, were squashed by those above and next to Mr. Citron (he was making money!) You guessed it – his luck ran out soon thereafter, and he lost around $1.5 billion, which bankrupted the County.

Be wary of “star players” whether they work for you, alongside you or elsewhere in the organization. When we are constantly told how good we are, we become overconfident. Overconfidence, the “I have seen/done this before” attitude, fueled by the lack of external scrutiny is a sure path to a major blowup.

Don’t let your guard down.

Special announcement: On November 15, 2008, I am running a half-day version of my course on Business Cases and Decision Making as a professional development event for the Project Management Institute. Because the event is sponsored by the PMI, it costs next to nothing to attend. If you are not in the Toronto area, why not come for the event and then spend the rest of the weekend sightseeing!

You do not have to be a project manager to attend. The content of this seminar is suitable for any professional, manager or executive.To learn more and to register, see http://pmi-lakeshore.org/notices/notice_20081115.htm

Recovering Distressed Projects (part 1 of 2)

Over the past few years, assignments involving “distressed projects” have been frequent…far too frequent for the maturing state of corporate project management. Requests to “recover” a project that has strayed into the territory called “distressed” usually come complete with a “hair’s on fire” urgency to locate and solve issues including emotional distress, protectionism, and a myriad of other valid reasons for the current condition. Amidst the chaos and high-emotion, the project must be assessed without prejudgment or bias, and lead to a path of recovery. This two-part series will deal with a consulting life-cycle approach to uncovering issues that have contributed to the distressed condition and recovering as many of the project’s original objectives and expectations as possible. Distressed projects have no industry preference; they are equal opportunity employers. Therefore, the practices discussed here are applicable to all industry types.

Defining Distress
In our consulting practice, we generally use the term “distressed” to represent a project or program that is 20%> off its cost and schedule baseline targets, exhibits missed milestones and has missed key deliverables. For the sake of recovering a project to its original scope expectations, the earlier the project is recognized as “sliding” the better. You may be asking, “Why only recover the scope expectations?” In many recovery efforts, our involvement begins well beyond the beginning phase of the “slide”. It is a foregone conclusion that the schedule and budget will need to be expanded to allow for original scope expectations to be met. In cases where schedule and budget cannot be expanded, scope is decreased to meet these constraints. PM stands for project management…not project magic! When a project has slipped into serious distress, recovering scope expectations in a stressful environment without major time and cost overruns is a feat in and of itself.

The Basic Life-Cycle
Although all distressed projects have unique issues, we have had success in using a basic and consistent life-cycle approach. The four-phase life cycle pictured below (truncated) has been developed over time and over many of these types of assignments. It is free of non-value added deliverables and is aimed at quickly and accurately getting to the heart of the distress, implementing the corrective action plan, executing and controlling new deliverable development, and executing formal project closure practices/processes.

Entering Phase
Someone once asked me why we call it “entering” and not “initiation”. My response was that the project already had an initiation phase. We are not initiating a project; we are entering a project that is in progress and has specific history associated with it. The term “entering” reminds us that we are not starting with a clean slate. To the contrary, we are in the middle of something failing that requires professionalism, patience, insight, tact and critical thinking in order to make a positive impact. Also, we are reminded that entering in the middle means we must exercise diligence to quickly get caught up on the underlying context of the project. This requires much listening and observation.

Scope Development
Whether we are consultants or internal resources, developing the consulting scope to recover a distressed project generally involves achieving clarity around and documenting the following areas:

  • Initial project expectations (history)
  • Current organizational assessment of the project
  • Expectations of the recovery assignment
  • Scope of Authority: The party or individual who has brought us into the project and our scope of authority going forward
  • Internal Contacts and Key Resources
  • Agreement on our approach (or variations) to the assignment

Schedule Initial Interviews and Data Gathering
In order to properly assess the project, we must interview a varied group of individuals who are directly and indirectly involved with the project. Generally (and hopefully), the individual responsible for our involvement with the project will have identified the organization’s key resources. At a minimum, the following resources should be interviewed:

  • Project Sponsor and/or Steering Committee Members
  • Project Customer
  • Project Manager and Staff (collectively and individually)
  • Key Functional Managers
  • Key Technical SME’s and/or Team Leads
  • Schedulers, Controls Resources, and PMO Resources (if applicable)
  • Key Project Team Resources (formal and informal leaders)

As mentioned earlier, each will have a story to tell about the original intent and why they feel the project has declined to its current status. One must be careful not to get hooked into the emotion of the situation. I recently entered into a very large program that was in a critical state. The emotions were highly charged…fingers being pointed in all directions and mistrust was on the rise as various functional groups took up their positions of defense. Experience teaches one to get past the emotion by calling them back to the real events…what happened (not why) versus their opinion of what happened, i.e., the “news” not the “weather report”.

Also, when one gets caught up in the emotions of the project, it is easy, with no malice aforethought, to agree with folks about just how distressed the project is. As innocent as this may be, it should be avoided at all costs. One of the first cautions of “entering” into a distressed project that will assist us in being quickly accepted as a non-biased pair of “cold-eyes” is being very careful not to “call the baby ugly”. Regardless of the current condition of the project, many people have worked very hard and generally have done what they thought to be the right thing. They have been surrounded by the project daily, which, after a while tends to limit one’s observations and insights. We come in fresh and our lack of specific history and emotion allows us to see things they may not. A good rule to use is not to make any observations or pronouncements (public or private) until you have thoroughly assessed the current situation. Project resources appreciate this type of professional restraint and are much easier to work with if they are not on the defensive.

Analysis and Assessment Phase
Depending on the point of entry, i.e., the level of current distress, this phase can be the most labor intensive of the assignment and not a glamorous one either. This is where the picture of the project, past and present, comes together for us. One must have a great deal of tact, yet possess the tenacity of “Lieutenant Columbo” in order to get to the nexus of the distress without alienating everyone at the same time. We will need to maintain very professional relationships during this phase as we will need buy-in and validation for our proposed solution later on.

Conduct Initial Interviews – Data Gathering, Documentation and Data Review/Evaluation, and Probative Interviews
Although distinct, the three processes above share enough commonality for us to discuss them together in this format. Many of the initial interviews will give us access to the project’s required documentation/data. In some instances, the data may be presented to us prior to the interviews. I prefer the latter. Having an opportunity to examine project documentation/data helps me form pointed questions for the interviews. This helps keep the participants focused on what happened, out of the emotional realm. From the consultant’s point of view it helps to keep the interviews from becoming a blur of repetitive conversations.

Once the first round of interviews and documentation/data review has been executed, we will conduct probative interviews that will be used to “drill” into specific areas uncovered earlier. Projects create a great deal of documentation and we can get overwhelmed if we allow the client to make a doc/data dump. To begin with, we will review the following specific documentation:

  • Charter and Project Approval Documentation
  • Project Charter (Initiation Mechanism)
  • Scope Statements (preliminary and definitive), Scope Development Documents, Reviews, and when Scope was “frozen”
  • Baseline Development Documentation
    • Project Estimates including basis of estimate documentation (ROM, Conceptual and Definitive; consistent with project size and complexity)
    • Project Schedules (with resource loading)
    • Project Design Basis Documentation, Reviews, and when Design Basis was “frozen”
  • Project Execution Plan Elements including (at a minimum)
    • Communication Management Strategy
    • Scope – Change Management Strategy
    • Risk Management Strategy
    • Procurement-Vendor Management Strategy
    • Project Controls Management Strategy
  • Integration – Handover – Closeout Management Strategy

Many times, these documents-artifacts have not been created. Or, they were created in order to gain project approval and have not been kept up to date; both are signs that project execution planning may not have been robust enough. Benchmark studies confirm that a lack of execution planning is a key cause in project distress and failure. We will discuss execution planning in detail in Part II.

Developing Conclusions and Solution Approach
This area is where experience plays a predominant role. As previously mentioned, projects are unique in their specific characteristics, yet sources of distress usually align with benchmark findings and common empirical results from one distressed project to the next. This certainly isn’t a rule yet; we do see many of the same “snags” from project to project. Below are just a few of the common distress factors we have seen in the past few years:

  • Ineffective and untimely senior management decisions
  • Ineffective expectations transfer from client to provider (contract terms misunderstood)
  • Ineffective Stakeholder Communication
  • Lack of Execution Planning
  • Lack of Scope and Design Basis Freeze prior to final estimation or definitive contract terms
  • Project or Program is beyond the experience level of the Project/Program Manager
  • Inadequate project structure and/or resources

Solutions are comprised of specific responses to causal factors and vary project to project based on culture, organization, resource levels, management buy-in, etc.

Gaining Approval and Consensus (findings and solutions)
Difficulty or ease in gaining approval, validation, and consensus is usually and directly related to the level at which the causal factors occur. Strategic or senior management level – difficult, Operation or Management level – easier, and Tactical or team resource level – much easier. Regardless of the level, the solution(s) must be presented in a logical, “threaded”, and no-blame manner in order to gain approval and consensus across the necessary constituencies.

In the next and final installment, we will discuss execution planning, control and project closure in detail.

 


Tom Flynn, P.E., PMP is a founding partner and Vice President of Consulting Services at Advanced Management Services, Inc., Tom has initiated and spearheaded the development of the Project and Program Management Division which helped transform AMS into its current position as a leader in the Project Management Consulting and Training industry.

In addition to his technical project management competencies, he also utilizes his extensive training and experience in conflict management-resolution, change management and human development to successfully coach and mentor senior executives, project managers and project team personnel.

 

Are You a Better Person Today?

I write for Project Times once a month. Since the last time, I have started new projects, spoken to several new prospective clients, written a couple of articles and prepared for several speaking assignments. I have attended three industry events and a specialty seminar in London (UK). I have read two fiction books and two books related to my specialty. I have moved my house, got together with friends (several times) and enjoyed quality time with my family. Casting my mind back 30 days, I find that I am better today than I was then, for myself, for my clients and for my loved ones.
How have you improved yourself, professionally, since we last spoke?

Have you developed a better understanding of your current industry? Have you sat down for a coffee with a subject matter expert to tease out the precious tidbits of knowledge we all are happy to share, when prompted?

Are you a better communicator today? Have you picked up, or developed yourself, some dramatically useful visual aids or templates. Have you learned to project yourself? To listen to others?

Have you made a concerted effort to understand the strategy of the organization? Have you determined how your project or project portfolio fits into it? For Pete’s sake, don’t tell me it’s not your job!

You might have improved your business acumen by delving in to the world of finance and taking your skills to the next level from the basic understanding of financial statements. Financial language is what the business speaks, and a project manager who can’t is at a great disadvantage. In fact, not being able to converse with a CFO is often a career-limiting move.

How many times have you had a lunch with your project sponsor? What is more important for your project than developing a solid, trusting relationship with him or her?

Have you attended an industry event, read a specialty book and stayed on top of current trends? Have you given back to the profession by mentoring a colleague, delivering a presentation or writing an article?

If you haven’t, where are you heading?

Special announcement: I hope we can meet at ProjectWorld in Toronto. My presentation on Healthcare projects is at 3:45pm on April 16, and I am a panelist in a discussion on whether one size of PMO fits all settings, on April 17.

Creating a Successful Project Management Office

What is a Project Management Office?

The Project Management Institute (PMI) states that a Project Office may operate on a continuum from providing support functions to project managers in the form of training, software, templates, etc., to actually being responsible for the results of projects. Project Management Office (PMO) is one name used for this business function. Other names include:

  • Project Office (PO), 
  • Project Control Office (PCO), 
  • Central Project Office (CPO), and 
  • Project Support Office (PSO).

Depending on the organization, the role of the PMO might be to provide an infrastructure for centralized status and budget reporting, providing training and mentoring in project management best practices, creation of methodology templates for use by project managers, and / or completion of projects from inception to benefits realization.

Creating a Successful PMO

ust like building a house, to create a successful PMO, a solid foundation is required. One of the key building blocks for establishing and maintaining a viable PMO is continued executive support. All the templates and methodology in the world will not help you if you can’t get the main sponsors to realize the benefits of a PMO. With this support in place, the PMO can begin to initiate change in the organization.

The next big hurdle is to communicate the PMO mandate beyond the executives. The ability to provide business value and having a clear mandate are two ways to ensure the organization at large understands the importance of the PMO objective. Once this is demonstrated business departments should understand and appreciate what the PMO brings to the table.

Another hurdle to overcome, is removing the control stigma from the PMO. People often associate a PMO with the gathering of status data and providing methodology templates. In some organizations the PMO fulfills an internal audit role for status and budget tracking, this is not an appropriate use of PMO resources. In order to provide the most benefits to the organization, the PMO should be providing the methodology used to measure project manager performance. The actual measurement should be conducted by the organization’s internal audit department, and should not be part of the PMO mandate.

To ensure your PMO is providing value to the organization and the business departments it services, it’s also important to complete projects from inception to benefits realization. Too many PMO departments are guilty of providing only administrative and support functions for project managers. When the budget belt needs to be tightened, if the PMO has demonstrated its value to the organization by completing strategic high- risk projects, it should withstand any organizational restructuring.

One of the PMO responsibilities is to develop the organization’s project methodology, including the project templates. The true measure of a good PMO is whether it can “eat its own cooking”, actually using the templates it creates in PMO managed projects. This way the PMO can get a first hand account of how useful its tools and methodologies are to the organization, and how they can be improved.

The measurement of the benefits realized per project, and how those benefits align to the organization’s strategic objectives, is an important contribution the PMO can make. The focus here is on portfolio management. Do the completed projects contribute to the bottom line? Project benefits should be aligned to the organization’s strategic goals. PMO portfolio management provides the mechanism for evaluation of the overall portfolio health. This will be a key input to executive project prioritization decision- making.

With this foundation in place, a successful PMO can be established and can play a key role in building a successful organization.


Ian Gittens, PMP, is a senior consultant with SPM Group Ltd. specializing in project fulfillment, methodology development, project portfolio management, business process reengineering, change enablement, and the development and implementation of project management infrastructure. Ian has 20 years’ experience in project management, business analysis, and application development, supporting multiple customers such as financial institutions, third party logistics providers, distribution organizations, high-tech manufacturers and retail organizations from APAC, EMEA and the Americas. His past responsibilities have included program management of regulatory and compliance initiatives and enterprise resource planning technology implementations for various business verticals. Ian can be reached at [email protected], or 416-485-1584 X 243