Thursday, June 27, 2013

Note: This posting is a continuation to the topic posted on June 24th and relates to my project management workshop titled "10 Ways to Increase Your Project's Success". In this post I discuss one of the sources of project failure and how we may mitigate this risk to our projects.

Source 3 - Expectations Management
I believe this is the most common source of project failures. Expectations management is the effort where the project team tries to ensure their perceptions of the scope and scale of the project deliverables align with the project owners. In addition to understanding the initial scope this also entails tracking changes to the scope. Expectations management becomes challenging when the requirements are not know, ambiguous, or fluid. We must acknowledge the the scope of any project changes over time through either significant changes or minor changes. The minor changes over time (scope creep) can be difficult to manage and product tweaks implemented by the project team (feature creep) can be both difficult to detect and manage.

Effect on Project
Since the schedule and budget are directly related to the project's scope, any change to the scope most likely has an effect on the schedule and budget. Minor changes in project scope may be absorbed with the existing budget and schedule but as these changes add up (scope creep) the budget and schedule need to be adjusted. Failure to adjust the budget and schedule to accommodate changes to the project scope put the project at risk for being over budget and behind schedule.

Actions Taken by the Project Manager
The most important action a project manager can take is to be aware and track the defined project scope and any changes to the scope. Quite often project teams will use a change order process to formally recognize changes to the project scope in order to calculate the additional time and budget needed to include the change. The changes are then introduced as a proposal and presented to the project owner for review and approval. Using the change order process, changes to the project scope are not actionable until the change order is approved and the new budget and schedule are adopted. A part of making the change order process work is to educate the project owner about the association of scope with schedule and budget and also explain that the change order ensures the project will be more likely to stay on track for the planned budget and schedule. We should expect change and be happy to welcome these requested changes to our project but we must insist that we are able to reevaluate the project budget and schedule so that we may ensure the project can remain successful.

Next Source: Process Shortcuts

Wednesday, June 26, 2013

Project Failure Source 2 - Process Shortcuts

Note: This posting is a continuation to the topic posted on June 24th and relates to my project management workshop titled "10 Ways to Increase Your Project's Success". In this post I discuss one of the sources of project failure and how we may mitigate this risk to our projects.

Source 2 - Process ShortcutsProcess shortcuts are when the project manager, the project team, or the organization does not adhere to established standards and processes. This may include skipping steps in a project management methodology or software development methodology, partially completing steps, or ignoring the process altogether. These shortcuts typically occur when the level of project effort or time constraints add further pressure on the project team or if the team is unaware or not accountable for following the process or methodology.

Effect on Project
Basically, shortcuts are counter productive. The shortcuts are taken to reduce work and time but often lead to rework. The rework creates additional work for the project team, takes additional time, and may impact the overall quality of the project deliverables.

Actions Taken by the Project Manager
If the shortcuts occur as a result of either a perceived or real concerns over the value of the process steps the project manager should either educate the project team and stakeholders or work with the stakeholders to evaluate the value of the process and make revisions. The project manager, project team, and all stakeholders must appreciate the process to ensure it is followed. However, if it is determined that the processes are adding value but compliance is not observed, the project manager needs to encourage compliance with the team directly or through the support of the functional managers.

Next Source: Process Shortcuts

Tuesday, June 25, 2013

Project Failure Source 1 - Project Champion

Note: This posting is a continuation to the topic posted on June 24th and relates to my project management workshop titled "10 Ways to Increase Your Project's Success".  In this post I discuss one of the sources of project failure and how we may mitigate this risk to our projects.

Source 1 - Project Champion
The project champion is the strategic or executive-level project stakeholder supporting the project.  The project champion buys into the project benefits and is willing to help the project team clear hurdles, obtain the required resources, and navigate the political environment at higher levels of management.  The issue with the project champion is not with the individual themselves but rather the absence of a project champion.  A project may be left without a project champion if a champion is not assigned early on in the project lifecycle, if the champion leaves the firm, or if the champion loses interest in the project.

Effect on the Project
Without a project champion, the project is at risk for securing or retaining the needed funding, human resources, and other project resources.  The project may not be able to maintain the resources needed and fall behind or may be cancelled altogether.  The absence of a project champion may also result delays due to challenges in obtaining approvals and achieving cooperation from the organizational units and layers of management within the organization.

Actions Taken by the Project Manager
The project manager can proactively ensure a project champion exists by insisting the organization follow a project management methodology where a project champion is assigned before the project is approved.  The early assignment of a project champion is also beneficial to the project evaluation process to ensure organizational support exists for the project and the support is sufficient to ensure the project gains the resources needed to succeed.  Also, the project manager should sell the project to the current champion to ensure the champion stays engaged and supports the project.  The selling of the project to executives also increases support beyond a single champion and allows other champions to emerge in the event the current champion leaves the organization.

Addressing the risk of losing a project champion increases the project's success by securing executive or strategic support to ensure resources are available as they are needed.

Next Source: Process Shortcuts

Monday, June 24, 2013

10 Ways to to Increase Your Project's Success

This week I'm presenting project management workshops at The College of St. Scholastica's Brainerd and St. Clound (MN) campuses.  The workshops are titled "10 Ways to Increase Your Project's Success".  In these workshops I discuss the importance of Risk Management in managing projects and identify the most common sources of project failures.  As part of this workshop we discuss how these sources of project failure affect our projects and then we develop plans to mitigate these failure sources.

There are many websites, articles, and other publications discussing the top sources of project failures but I found the Whitten and Bentley (2007) text best articulates these sources of failure.  Below is my adaptation of the authors' list of sources of project failure:
  1. Missing Project Champion
  2. Process Shortcuts
  3. Expectations Management
  4. Variable Lock-In
  5. Estimating Techniques
  6. Optimism
  7. Resource Assumptions
  8. People Management
  9. Adapting to Change
  10. Insufficient Resources

Over the next several posts I will discuss each of these sources and describe how participants at the workshops view the impact of these sources of failure on the project and how we plan to mitigate these issues in future projects.

More to come...


Reference
Whitten, J.L., & Bentley, L.D. (2007). System analysis and design methods (7th ed.). Boston, MA: McGrawHill/Irwin.

Wednesday, June 19, 2013

The Value of Project Management

This week I traveled to Brainerd and St. Cloud (Minnesota) to give a project management workshop.  This workshop titled "The Value of Project Management" provided an introduction to projects, why projects are important, the purpose of project management, and the project management process.  As part of this workshop I provided a set of project management templates to serve as a rudimentary project management methodology.  I posted the slides for the workshop here and the project templates here.

This was the first of a three part workshop series on project management topics.  June 24th (Brainerd) and 25th (St. Cloud) I plan the same trip to present a workshop titled "10 Ways to Increase Your Project's Success" followed by "Maximizing the Impact of Your Projects" on July 8th (Brainerd) and 9th (St. Cloud).  You can register for these free workshops by clicking the hyperlinks above for the corresponding date and location.

Sunday, June 16, 2013

The Good News about IT Project Failures

While reading the April 2013 issue of PM Network magazine today I came across an article summarizing the PMI 2013 Pulse of the Profession report (Gale, 2013).  The author noted an overall decline of 10% for project success rates over the past four years.  This is different than the findings reported by the same author (Gale, 2011) from the 2011 Chaos report which showed an increases in success rates.

The difference between these two findings is that the Chaos report is based on IT projects while the PMI report is based on ALL industries.  The author suggested the Chaos report may have included higher success rates since ERP projects were not attempted during the recession and the PMI decrease in project success rates were due to organizations trying to cut costs and taking shortcuts.

These two trends and corresponding analysis appear to provide evidence that the low success rate of IT projects is due to higher-risk projects than any issues with project management practices.  The relationship with risk and success rates indicated in the Chaos report shows that IT project must have a risk plan in place; risk management is critical in IT projects.

References:
Gale, S. (2013, April). Finding the competitive edge. PM Network, 27(4), 39-43.
Gale, S. (2011, May). Failure rates finally drop. PM Network, 25(5), 10-11.

Friday, June 14, 2013

I'm Back

After almost a half a year I'm moving back to my blog.  Last December I attempted to shift my time from the blog to other forms of social media (LinkedIn, Google+, etc.).  My thought was to move to other forms of media where information could be shared through conversations rather than through a one way message.  This idea still seems appealing but the issue with these other forms of communications is that they support only brief dialog; we can' really offer sufficient analysis on a topic.  For this reason, I'm moving back to my blog.  I hope to provide more in-depth thoughts on topics and welcome a conversation through the comments feature (I will respond to comments).

Postings in this blog will align with my areas of research where I hope to use the blog to think through some of the readings I come across.  My research interests fall within project management, knowledge management, analytics, business intelligence, databases, technology and society, and systems thinking.  My posts will typically fall into these domain areas.

Skills to Look for in Project Managers

Today I read a brief article describing the eight skills to look for when hiring an IT project manager. The headlines caught my attention...