Skip to main content

Tag: Requirements

The Challenge of Evaluating EPM Software

Written by Cynthia Low on . Posted in Articles. 6 Comments on The Challenge of Evaluating EPM Software

It happens to me all the time. The mail arrives and in it is an RFP. They’re three dreaded letters around my office and I’ll tell you why. The “Request for Proposal” is a construct of purchasing departments, designed to compare vendors with similar products to sell. The RFP is supposed to list in exacting detail exactly what kind of proposal the client requires and the respondents are expected to prepare their proposal and give the best possible price to the client. The client evaluates all the proposals together and then knows who can give the best possible solution.


It works great when the client is looking to buy army boots or kitchen knives or storage containers. It’s virtually useless when used to purchase an enterprise system and here’s why:

First of all, let’s take a look at how we assemble the RFP. The beginning and end of the document are boilerplate. They list the process of how to respond and the legal terms of what responding may mean and what you must or must not agree to. In fact, most of this is not that useful, since if you are the winning bidder, you’ll need to go a whole new round of terms negotiations with the contracts people but either way, this is not our big concern. No, it’s the bit in the middle we want to talk about.

In the middle we’re supposed to have a list of those requirements in ‘exacting detail’. The client must assemble the various parties involved to see what they would like in our new enterprise system. Perhaps a committee is convened or a series of focused workshops to work through all the implications of each requirement. Perhaps there is a long period devoted to developing the business requirements that will resolve to system features.

If only…

In fact, what’s more likely is the project manager assigned to this project will have a short meeting, or perhaps two, during which he or she will make a request that the participants represent their departments by listing all the features that are important to them. Each person goes back to their group and sends an email saying “This is your only chance to have any impact on what we’ll need in the new enterprise system. Speak up now or forever hold your peace.” The departments respond in an uneven fashion. Some department members give the request serious consideration and submit a long list of things. Others give only a perfunctory response.

The project manager now assembles these items into a spreadsheet and adds a few columns: “Priority,” “Comment,” “Included.” The end result looks like this:

Instructions:
For each Priority enter:
M: Must have
I: Important to have but not essential
N: Nice to have
For each Included enter:
Y: Yes, this is included in your product
N: No, this is not included in your product
E: This could be included by adding additional effort which has been identified, scoped and priced into your proposal

Feature Priority
(M/I/N)		 Included
(Y/N/E)		 Comment
The enterprise system must

Gosh, it looks good so far, doesn’t it? The spreadsheet fills out quickly. For the more organized clients, on the internal copy (the one not sent to the RFP respondents) is a column called “Weighted”. This is where the relevant score weighting for each item is entered.

The project manager now merges line after line, categorizing them perhaps to make sure there are no big feature holes. In the end, what is received is a remarkable list of features that looks just like every EPM system brochure on the market today.

Now, the vendors get this list and scratch their heads. God knows, I’ve done it plenty. They look at the list of features listed and try to make sense of why some features are listed 2, 3 even 4 times but each worded a little differently. They try to reconcile some features which seem diametrically opposed to each other. They ask questions for features which seem deliberately vague like “The system must automatically transfer data with our internal LIMS environment.” Invariably the acronym LIMS is not explained and the details of what the expectation may be are not available.

But there is a profound problem with this process. Have you spotted it yet? The RFP is describing the solution not the problem. It’s a massive disconnect and no one ever talks about it. The purchaser or the project manager assembles a list of every feature all his or her users can come up with and presents that list to the vendors. But what is not at all clear is whether the delivery of those features will make the lives of anyone at the client company any better.

So, what happens? Vendors go through an exercise of preparing a hundred-page or sometimes a multi-hundred page response. The client receives several of these. The selection committee reviews them all. They all say the same thing: “We can deliver every feature you’ve described.” Sometimes vendors tick off every line item with a “yes”, even the ones that don’t make sense or are in complete conflict with other line items.

The hapless readers must wade through these documents trying to determine which vendor makes sense. The weighting scheme tells them what features are more or less important but the scores after everything is done are very close. The biggest impact on scores? The neatness of the work! I know, it sounds childish but ask around and see if it’s not true. The vendor with the most colourful, neatest, easiest to read response always scores well.

Now a short list is assembled and a couple of vendors are invited to do demonstrations. Typically the meetings are a couple of hours or less. In the most frustrating cases, the client asks that the demonstration look exactly like what their system will look like after it’s purchased, configured, populated with data, customized and enhanced. This obviously can’t be presented. But, the meeting is important because it’s the first time the vendor gets to meet the end users and ask “What on earth is it you need to accomplish? What are you suffering from? What is the problem?”

In the end, purchasing decisions are often made one level above the selection committee anyway. An executive makes that decision not based on a requirement analysis but on the recommendation of a trusted advisor, or a friend or colleague who once bought a similar system. Will it work? Sometimes and sometimes not but it’s a certainty the system purchased was not done based on what the company is struggling with.

“But that’s the best purchasing process we can come up with,” I’m sometimes told.

I truly doubt it.

If you’re considering moving to a new EPM system in the New Year, I’ve got a couple of recommendations for your purchasing process.

First, start with the problem, not a description of what you think the solution should be. List the business challenges that you are finding it difficult to overcome. They can be articulated in terms of business decisions that you find difficult to make or business process inefficiencies that you wish to improve. Saying “the system must help us decide to increase or decrease our future resource commitments with sub-contractors but delivering resource capacity planning such that we can see a projection for the next 90 days of resource requirements and resource capacity.” is incredibly more powerful than saying “The system must have resource capacity planning reports.”

A vendor who understands the business challenges will feel more latitude to craft a response which may be more creative and, even better, in ways that you’ve never imagined.

Next, put less attention on the vendor demonstrations and more on vendor references. Probably the most valuable thing you can do during this process is arrange to visit the sites of other clients of the vendor. A vendor salesperson demonstration will always look sharp but a real client will almost always be honest enough to explain the parts of the deployment that went great and those which were more challenging.

Finally, make sure that management gets on board with this process early and stays involved. There’s little more debilitating than having a selection group work at something like this for months only to find out that none of their work will be considered when someone from senior management makes the final decision.

Happy buying!

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected]

 

The 21st Century

Written by Cynthia Low on . Posted in Articles. 11 Comments on The 21st Century

Since its emergence in the early 1970s, IT has been built from the bottom up. Applications to support the business were deployed as the need arose to increase efficiency and support growth. Because systems were not architected from the top down, the result has been a legacy of inconsistency, redundancy and the type of complexity that makes change difficult without destabilizing the whole system. As organizations compete in the global economy, they need systems that are agile, easy to change and responsive to new business needs.

In mature organizations, IT is currently undergoing a twofold transformation. One, the IT culture is changing from a provider of technology to a provider of valuable services, and two, IT assets, products and services are being aligned with business strategies. Project management and business analysis are critical to making the transformation succeed.

A New Discipline for IT

Young or immature IT groups focus narrowly on technical implementations. Here, IT is merely a provider of technology, responsible for maintenance and support. Project management centers around budget, schedule, scope and system specifications, and much time is spent recovering from failures, modifying or replacing components to eliminate problems, carrying out additions, modifications or removals to introduce improved functionality. Because the number of incidents, problems and changes exceeds staff capacity, IT needs a way to determine how it can best use its resources so that the issues it does tackle will yield the most business benefit. The only way that prioritization can be accomplished is with guidance from customers and users, but that discussion cannot be carried out effectively in technical language.

This is where ITSM (IT Service Management) comes in. It provides an effective framework of tools and templates for helping IT groups become more adaptive, flexible, cost-effective and service-oriented. ITSM drives fundamental change within the IT organization, from how it manages its processes, technology assets and vendors and deploys personnel, to how staff view their organizational roles. An ITSM-based IT organization seeks to understand the customer’s service requirements, agrees with the customer on the delivery of the service, and operates and evolves the service to contribute measurable results to the business.

A proven set of best practices to implement ITSM is ITIL (IT Infrastructure Library). ITIL was developed by the U.K. government and has been used in Europe for many years, but is just now beginning to make inroads into the U.S. Designed to define and streamline IT services, ITIL’s practices were drawn from public and private sectors internationally. Both ITSM and ITIL are about efficiently and effectively leveraging IT to achieve desired business outcomes, but ITSM answers the question, “What do we want to do as an IT organization?” while ITIL is one way of addressing, “How are we going to do it?” ITIL and ITSM help IT organizations deliver IT services that are:

  • Cost-justifiable
  • High in quality and are measured, reported and reviewed regularly
  • Managed efficiently (best use of resources) and effectively (achieving the intended results)
  • Prioritized by activity relative to the business impact
  • Monitored for change so that change is controlled to minimize negative impact on services
  • Aligned to and drive business strategy

According to industry analysts, 80 percent of business processes are run on IT. Just as corporations are reinventing themselves to comply with new regulations such as Sarbanes-Oxley, so too has IT had to reinvent itself to become a disciplined organization whose activities are aligned with the business and result in direct, measurable business benefits. The first step in achieving this alignment is to understand how the business works. This is done by building process maps and defining business rules as necessary to document how the business flows value through the organization to its customers. Gaps and misalignments between business and IT are brought to light so that hardware and software can be realigned. The transformation process amounts to the building of a strategy-execution framework, both on the business side and the IT side.

The Role of Project Management

Traditionally, projects were spawned within IT. Today, a mature IT department does not implement upgrades and infrastructure projects unless there is a business advantage to doing so. Effective business management depends on successful IT projects, and the practices of project management and business analysis intensify the impact of ITIL. ITIL has a strong focus on managing changes to maximize benefit (business outcomes) while minimizing risk. Because changes are typically implemented as projects, project management is the foundation for successful integration of IT changes into the operational environment in a way that meets IT service quality and availability targets. Most organizations that are implementing ITSM/ITIL are tackling the challenge by addressing IT services piece by piece in order of importance. They are forming project teams and managing changes as projects so they can track the investment in new tools and processes.

Competency in project management is thus a vital contribution to realizing:

  • Lowered risk
  • Cost efficiencies
  • Ability to hit the planned/estimated scope, budget and schedule targets that underpinned the business case

In the past the project manager’s goal was to bring projects home on budget, on time and with the full scope. Now there is a fourth success criteria and expectation, which is that the business benefits were actually achieved with positive ROI. That means the business should have realized more in benefits than it spent to develop and operate the new solution. A challenge in this regard, particularly in decentralized companies, is that IT managers are often doing hands-on engineering work, as was customary with the 1970s reactive approach. Rather, they should be managing the work and allocating resources to the most valuable projects and activities.

The Role of Project Portfolio Management

The practice of project portfolio management is a form of IT governance. It ensures that IT is investing in the most valuable projects and allocating resources to projects in order of priority. Project teams that are performing strategic initiatives are resourced while trivial projects that consume resources without returning significant business benefits are back-logged.

Expect a learning curve with portfolio management/IT governance because the business is used to sending any kind of request to IT and having it fulfilled. Portfolio management encourages organizations to work collaboratively to establish a new structure for decision-making and prioritization of IT work that takes into account the benefits of projects all across the enterprise. This is a new leadership practice in the way changes are approved at the senior level. The transformation task at hand is daunting because of IT’s legacy of complexity. Practicing portfolio management to focus on the most strategic products and services first saves scarce resources, and keeps personnel from getting overwhelmed.

The Role of Business Analysis

According to a 2004 survey (The Standish Group, Third Quarter Research Report), 53 percent of IT projects in the U.S. were over time or over budget, 18 percent failed and only 29 percent succeeded. According to the Standish Group’s 2006 Chaos Report, little had changed: 46 percent of IT projects were over time or over budget; 19 percent failed and just 35 percent succeeded. Nearly two thirds of all projects failed or ran into trouble. The reason for the dubious success record of IT projects is that business analysis is not applied and maintained throughout application development and implementation.

Poor business analysis not only impacts business stakeholders, who don’t get what they paid for, but it also adversely affects project management. Poorly stated requirements prevent accurate estimation and effective resourcing. This in turns leads to poor application development and forces project managers to repeatedly re-initiate or even directly carry out requirements management activities to address deficiencies.

The primary responsibility for requirements’ management belongs to the business analyst (BA), as defined by the International Institute of Business Analysis (IIBA). While subject matter experts understand the language of requirements in their particular domains, the BA speaks both business and technical languages, but focuses exclusively on the business. He or she understands and owns the process through which requirements are translated from business strategy to successful solutions. The BA’s enterprise view of requirements management drives alignment through all levels of the organization.

Unfortunately many IT groups still insist that they do not need a BA because most of their projects are “technology projects” or “exclusively engineering.” Every project should derive from business needs. Therefore, every project’s decision-making process should be driven by a BA. Without a BA who focuses on the business case and makes sure there is a business benefit, the IT organization is not fulfilling its responsibility.

Culture Change for the New Millennium

IT can no longer function as a set of discrete tools supporting discrete business processes. Today, critical business processes are highly dependent on and integrated with IT; the two are essentially inseparable. IT assets need to be tightly focused on meeting the needs of internal customers, if organizations are to respond flexibly and quickly to markets, customer demands and regulatory obligations. In the early 21st century, a perfect storm is gathering to change the culture of IT, to govern investments in IT and to use IT as a competitive advantage to impact the bottom line. The challenge of the transformation is immensely complex and should not be undertaken without competent project management and business analysis.

Kathleen B. Hass, PMP is Senior Practice Consultant at Management Concepts, and Director at Large and Chapter Governance Committee chair for the International Institute of Business Analysis (www.theiiba.org). She is the author of Managing Complex Projects: A New Model (Management Concepts, October 2008). Since 1973, Management Concepts, headquartered in Vienna, VA, has been a global provider of training, consulting and publications in leadership and management development. Management Concepts is a Gold International Sponsor and an Endorsed Education Provider of IIBA. For further information, visit www.managementconcepts.com or call 703 790-9595.

Building an Initiative Oriented Culture

Written by Cynthia Low on . Posted in Articles. 9 Comments on Building an Initiative Oriented Culture

Today’s businesses are pushed and pulled in many directions. Strategy execution has been recognized as critical by leaders and organizations to give the edge and competitive advantage over competitors, and is needed even more in the turbulent times we face. And yet, statistics and results indicate that most organizations do not execute strategy successfully – in fact less than 34% of corporate strategy is ever executed and many initiatives fail to deliver the expected and necessary results. Common challenges include: introducing and managing change, rapidly changing landscapes and markets, and the effective use of human capital.

Role of Culture

One of the critical factors SPM has seen year over year while working with clients on their key strategic initiatives is the impact of culture. The right culture can overcome gaps in infrastructure and process. An adverse culture can sabotage even the best process and intent. In many instances culture is often skirted around than considered an important contributor to more effective strategy execution. We also see a very strong ‘tension zone’ between executing strategic initiatives and running the day-to-day business as usual operations (BAU). The ideal culture for ‘business as usual’ may be different than what is needed for initiative execution and can further exacerbate the tension zone between strategy execution and BAU. A recent study reported that 72% of executives indicate that a culture gaps exists within their organizations and is interfering with strategy execution and goal achievement. And as Connie Curran wrote ‘Culture will eat strategy for lunch every time’. All these factors point to the role of culture as a powerful component of an organization’s success, laying the foundation for productivity and progress.

In SPM’s Enabling the Effective Enterprise model an Initiative Oriented Culture is one of three key underpinnings. The diagram below shows the key components of an effective enterprise and how they interact in a continuous transformation cycle.

Developing an Optimal Culture

So what is culture and what is the optimal culture for an organization? By definition, culture is a set of stated and unstated, explicit and implicit beliefs and assumptions shared by a group. It is often invisible and unconsciously at work, yet ever present and lasting in its impact. Culture shapes and harmonizes behaviours of all members in the organization or group. There are generally three functions of culture in the workplace: simplification and adaptation of decisions, integration and affiliation, and member motivation and activation.

The culture components to consider in an initiative oriented environment are:

  1. Values: behaviours and attitudes have a powerful impact on the outcome by teams charged with strategy execution and include: leadership, empowerment, trust, risk tolerance, engagement and results orientation.
  2. Process: strong, repeatable processes that also address the risk inherent in temporary endeavours (such as initiatives, programs and projects) will play a critical role in strategy execution; best supporting processes should include: clarity and communications of strategy, knowledge sharing, change management, innovation, and organizational alignment.
  3. Structures: the environmental structure within which work is done for initiatives versus ‘business as usual’ is different and will be a key enabler to success. Key factors include: team structures, hhiring practices, alignment of reward and recognition systems, recognition and usage of change agents, and effective use of virtual teams.

Building awareness and deliberately designing culture appears to provide higher cohesion around priorities and establishes ownership for behaviours and beliefs that impact success, rather than leaving it to chance. Culture can accelerate getting to the next level of success or just as easily act as a drag. By recognizing the need to fit culture with strategy and in particular allow for culture to drive execution, organizations can target specific actions to build the culture needed for successful execution of strategy.

The optimal culture for one organization will not be the same for another. Each organization needs to recognize its own unique set of culture patterns, strengths and areas of collective practices that represents its culture. The strategy or combination of strategies for an organization will determine the best culture. For example, a cultural environment that supports a strategy of innovation may not be the same as one of a high reliability organization. Culture may need to change over time as strategies shift. The evolution of the organization and its maturity will also guide the development of optimal culture.

Enabler or Barrier?

At a recent conference SPM launched a national survey to examine culture as an enabler or barrier to strategy execution. 62% of the respondents indicated their organization does not have the right culture to allow for the effective implementation of strategy. Surprisingly comments indicated that most people feel culture is a positive factor, in other words an enabler rather than a barrier, despite the response to culture misfit with strategy. 58% indicated there have been attempts by their organization to change or alter culture deliberately. This demonstrates some level of understanding by leaders of the importance of culture. As Isadore Sharp states: ‘If you don’t understand the culture of the company, even your most brilliant strategies will fail. Your vision will be resisted, and all kinds of things will go wrong.’

The survey also tracked key indicators that impact strategic initiatives. Key positive cultural indicators included:

  • 66% of respondents felt that they had leadership support for their initiatives and 71% felt that they were being motivated to succeed.
  • Most respondents felt strongly that they understood how their work contributed to the overall strategy of the organization and also clearly understood priorities and expectations of them

Key negative cultural indicators:

  • Only 33% of respondents indicated that they had learned from their past experience – success or failure
  • Majority of respondents felt that they did not have the right mix of people on their team and that conflicting interests of team members interferred with success of initiatives

Conclusion

While the survey results show a certain level of awareness of the importance and positive impact culture can have on strategy execution there is still a need for more deliberate design and implementation of culture. Building an initiative oriented culture can create a much higher success rate on strategy execution. It must be deliberate, encourage an appreciation of culture strengths, rapidly focus on culture weaknesses, build cohesion around strategic priorities, and generate high performance results.

Catherine Daw, MBA, PMP is CEO and President of SPM Group Ltd. She provides the vision and leadership needed to evolve the firm including the current corporate direction to enabling the effective enterprise through strategic initiative management. Her focus is on results that matter to SPM’s clients and to ensure solutions exceed client expectations, save time and money, and help clients achieve superior business benefits. Catherine holds a Bachelor of Science degree in Mathematics and Computer Science from Queen’s University and a Masters of Business Administration from York University. She is an active member of the Project Management Institute and is a certified Project Management Professional (PMP) as designated by the Project Management Institute. Catherine can be reached at [email protected]

Ruchura Chatterjee, MA, PMP is a Senior Consultant with SPM Group Ltd. and has over twenty five years experience managing progressively larger and more complex departments and projects. She has held positions as Program Director, Director Client Services IT, Director Model Operations in a business unit, and managed Application Development and Business Systems functions. With a M.A in Economics from Calcutta University, India, Ruchira has also completed a Company sponsored Executive Management training program at Kellogg, Northwest University. She is a Project Management Professional (PMP) as certified by the Project Management Institute (PMI). Ruchura can be reached at [email protected]

Recovering Distressed Projects (part 1 of 2)

Written by Cynthia Low on . Posted in Articles. 12 Comments on 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.

 

Finding the Right Project Manager

Written by Andrew Miller on . Posted in Articles. 15 Comments on Finding the Right Project Manager

In an ideal world, we are all great PMs and there should be no skill involved in picking the right PM for a project. But in the real world, there are PMs with many different skill sets and strengths (and of course weaknesses). Below are just a few things to consider when selecting a PM for a particular project:

  1. Leadership ability
    First and foremost, a PM needs to have strong leadership abilities. This means the ability to motivate, lead by example, act with integrity, handle crisis and stick to deadlines. There are not many things that will cause a project to fall off of the rails faster than a PM who does not inspire the team to strive for success. Look for someone who has consistently proven that they can successfully lead teams, or someone who is begging for the opportunity to lead.
  2. Fit with the project and the team
    Although PM skills are fully transferable across industries and projects, there does need to be a good fit with the team and project. Sometimes the right PM can get more out of the team than was thought possible and the wrong PM can cause a perceived excellent team to under-perform. Look for a PM who can recognize different personality types and knows how to leverage their strengths. It wouldn’t hurt if they can also focus on having fun and getting the work done.
  3. Discipline
    I have written about this before, but the one thing that PMs need to have that others do not is discipline. Discipline to track the budget and the project plan; discipline to follow-up on assigned tasks; discipline to track down suppliers for payment or required work products. Discipline is what can set a good PM apart from a bad one, so look for those PMs who are disciplined in their work and require that in those with whom they work.
  4. Creativity and flexibility
    As important as it is to be disciplined, it is always important for PMs to be creative and flexible. Things are not always going to go as planned, so you need a PM that can adapt to change and be creative in finding solutions. Look for PMs who work well under pressure and are able to come up with creative solutions when the pressure is on and deadlines are approaching.

Of course, there are other important characteristics in finding the right project manager and I welcome your comments about any I may have missed (or on those that I have provided above).