Posts Tagged Project Management

The Elephant in YOUR Project – Part 3 Risks

Project Risks

Project Risks

 

 

The Elephant in YOUR Project – Part 3 Risks

Many project managers use complexity and risk synonymously.  They are related, but not the same. Project risks are qualitative and quantitative issues or events which could lead to negative consequences.  Risks can be prevented, mitigated, or repaired if they become an issue. Increased project complexity does not create risks, but increases the severity and impacts of each risk on the project efforts.

Your project risks can be weighted and objectively measured.  A project’s risk and be grouped into five categories:

  1. People/Team Risks – morale, skills and experience, staffing, contractor capability, etc.
  2. Process Risks – scope creep, project management, project planning, project controls, scheduling, etc.
  3. Technology Risks – technology quality, technology newness, expectations versus requirements, etc.
  4. Finance/Budget Risks – budget approval, budget adequacy, scope changes, reporting, etc.
  5. Legal Risks – contract negotiations, contract management, terms and conditions, etc.

Once identified, risks management and reporting is the responsibility of the project sponsor and project manager(s).  Risk prevention, mitigation and repair are the responsibility of all project team members as assigned by the project manager(s).  Each significant risk should be formally reported and tracked in every project status report, and discussed effectively with the project steering committee.

So is your project a House of Cards, or are you managing project risks effectively?

 

For a free example of a Project Complexity Assessment and Project Risks Management Tool, download at:

Palomino Free Downloads

 



Tags: , , , , , ,

The Elephant in YOUR Project-Part 2 Complexity

Complexity

Complexity

 

The Elephant in YOUR Project – Part 2 Complexity

In Part 1, we discussed the research and statistics of project success or lack thereof.  For decades projects or change have repeatedly been challenged and over half do not meet all of their expectations or are failures.  My experience indicates one of the primary reasons, or The Elephant in Your Project, for these continued poor results is the lack of formal project complexity assessment and aggressive project risk management – the responsibility of the project sponsor and project manager(s).

In Part 2, we expand on a project’s complexity and how it affects the ultimate outcome of your projects.  In review, a project is a process or series of processes.  A process’s complexity – defines, qualitatively and quantitatively, the relative difficulty, time consumption, resource requirements and skill requirements necessary to successfully complete.  The more complex the process or project – the more difficult, time consuming, resources intensive and more experienced skills are required.  Complex projects are rarely successful and many times are failures.  Of course, the lower the complexity, the greater chance a project meets all of its expectations.

Three major components determine a project’s complexity and can be objectively weighted and measured – (1) Operational/Technical complexity; (2) Business complexity; and (3) Organization complexity.  Within these components, complexity is primarily the result of the “4-S’s”: structure, size, scope and skills. Criteria examples include:

  1. Operational/Technical – Technology requirements, technology distribution, operations impacted
  2. Business/Process – Business units impacted, business process maturity, number of people/users impacted
  3. Organization – Project manager’s skills/experience, project duration, project team size/location, project team skills/experience

Project complexity must be assessed up front during overall project planning. Complexity components must be addressed and reduced at that time before being locked in after the project(s) begins.  Some obvious ways to reduce complexity are:

  1. Break project into smaller, more manageable efforts which reduces project team size.
  2. Reduce each project effort scope and duration, and thus people/users impacted.
  3. Staff each project effort with more highly skilled project team members and/or provide training.
  4. Staff project with highly experienced project manager(s) and team leader(s).

Increased project complexity does not create risks, but increases the severity and impacts of each risk on the project efforts.  We will further discuss project risks and risk management in Part 3.

 



Tags: , , , , ,

The Elephant in Your Project – Part 1

The Elephant In Your Project

The Elephant In Your Project

 

The Elephant in Your Project – Part 1

The high ‘failure’ rates of IT and business projects have been documented for over four decades by numerous studies and publications.  The Standish Group International reported in 2001 that around 23% of projects are failures, and 49% are ‘challenged’.  Doing the math indicates that only around 28% of projects meet their expectations.  A more recent IBM study in 2008, Making Change Work, indicated that on average 41% met all expectations and 59% missed one or more expectations, or failed completely.  Even worst news from IBM was that companies that were ‘novices at projects for change” had only 8% of projects that met all expectations.  Houston we have a problem!

My experience indicates one of the primary reasons, or the Elephant in Your Project, for these continued poor results is the lack of formal project complexity assessment and aggressive risk management – a responsibility of the project sponsor and project manager.  The IBM study, only one of a few, also indicated that the lack of recognizing the project’s complexity was a major factor in a project’s success or failure.  Yet only 18% indicated their efforts fully addressed project complexity and risk.

Every project, IT or business, is a process – a process with varying degrees of complexity.  A process’s complexity: defines, qualitatively and quantitatively, the relative difficulty, time consumption, resource requirements and skill requirements necessary to successfully complete.  The more complex the process or project – the more difficult, time consuming, resources intensive and more experienced skills are required.

Many project managers use complexity and risk synonymously – but they are not.  A project risks:  are qualitative and quantitative issues or events which could lead to negative consequences.  Increased project complexity increases a risk’s possible impact.  Risks can be prevented, repaired if they become an issue or mitigated.  Complexity is not an event and is harder or impossible to prevent, repair or mitigate once the project begins.

So why do most project sponsors and managers do a lousy job of complexity assessment and risk management?  A few reasons are:

Lack of awareness, skills, training and/or experience

Internal politics

Lack of formal assessment/ management process that is consistent and repeatable

Lack of assessment/management reporting and tools

 

Part 2 will discuss more on assessing complexity and Part 3 will discuss risk management.

 



Tags: , , , ,

Was Your Project a Success Or . . .

Project Balance Scorecard

Project Success

Just started or completed a project? How will you know if it was a success – met or exceeded expectations? Or how will you know if it was not a success – didn’t meet expectations or failed? Which stakeholders’ expectations are important? What can be improved to insure more success next time?

Did you know that most software development (SD) organizations do not have a process or commitment in place to even try to measure a project’s success, failure or areas for improvement? These are usually CMM Level 1 organizations, Chaotic. CMM Level 2 SD organizations, Repeatable, typically has a process that measures a projects success, or lack of, whether it was “On Schedule” and/or “On Budget”, but this measurement falls short of answering the questions above.

So what process and commitment is needed to answer all of the questions above. Many CMM Level 3-5 SD organizations have implemented Project Balanced Scorecards (PBSC) as the process and tool to give a ‘balanced’ view of project success, or not, and areas for improvement.

A good PBSC follows the guidelines of the Balanced Scorecard Institute and based on The Balanced Scorecard from Kaplan and Norton. The PBSC starts with identifying all key stakeholders for a project including:

1) Business stakeholders
2) IT Service Delivery, operations, stakeholders
3) Customers
4) Employees, project team

These stakeholders determine a project’s level of success and areas for improvement. Next is to develop criteria for each stakeholder’s focus on the project’s success. Major criteria categories and criteria might be:

1) Financial Focus – Business financial stakeholders

2) Service Delivery Focus – Operations and support stakeholders

3) Customer Focus – Business and external customer stakeholders

4) Employee Focus – Project team stakeholders

The above criteria contain quantitative and qualitative areas of focus to determine a project’s success – a balanced view.

For an example of a Project Balanced Scorecard, check out our web site at Palomino Consulting Group – Products



Tags: , , , ,

Danger – Thin Ice

Risk

Risk

The high ‘failure’ rates of IT projects have been documented for over four decades by numerous studies and publications.  The Standish Group International reported in 2001 that around 23% of projects are failures, and 49% are ‘challenged’.  Doing the math indicates that only around 28% of IT projects meet their expectations.  My experience suggests one of the primary reasons for these continued poor results is the lack of formal, aggressive IT project complexity and risk assessment and management – a responsibility of the IT project sponsor and project manager.

Software development is a process – a process with varying degrees of complexity.  A process’s complexity, therefore, defines, qualitatively and quantitatively, the relative difficulty, time consumption, resource requirements and skill requirements necessary to successfully complete.  The more complex the process – the more difficult, time consuming, resources intensive and more experienced skills are required.  Many project managers use complexity and risk synonymously – but they are not.  Project risks are qualitative and quantitative issues or events which could lead to negative consequences.  Risks can be prevented, repaired if they become an issue or mitigated.  Complexity is not an event and is harder or impossible to prevent, repair or mitigate once the IT project begins.

So why do most IT sponsors and project managers do a lousy job of complexity and risk assessment and management?  A few reasons are:

  1. Lack of skills – training and/or experience
  2. Internal politics
  3. Lack of formal assessment and management process that is consistent and repeatable
  4. Lack of assessment, management and reporting tools
  5. Lack of emphasis in CMM, ITIL and other methodologies

 

What is the complexity of your current project?  What are the five major risk areas?



Tags: , , , , ,