As the saying goes, “history has a way of repeating itself.”  That said, a good historian looks back at what has happened previously and avoids the same mistakes.  The above-referenced article deals with some of the main reasons why projects fail. 

Definition: “A project is considered a failure when it has not delivered what was required, in line with expectations.”

The below are main reasons why projects fail per the referenced article:

• The wrong business requirements have been addressed
• It’s not possible to deliver the business requirements
• Poor governance
• Implementation is poor
• People lose focus on the project’s benefits
• The environment changes

At first glance, the first two failures seem almost too simple to be on the list.  However, when you start reading through the article, you may find that these failures are easy to achieve.  The news is always scattered with project failures that have addressed the wrong business requirements because the requirements weren’t defined correctly at the beginning.  In addition to addressing the wrong business requirements, a poorly defined project has the risk of scope creep (expansion of the project scope) as well, often leading to costly and delayed projects.

 Failing to recognize that it’s impossible to deliver business requirements is also an issue in the project definition stage, but it is easy to do.  Business requirements may include resource restrictions, time constraints, or budget constraints.  I’m currently working on a project that this is a major concern of mine.  Often times, projects are started by someone higher up with a rosy picture of how the project will be completed.  Unfortunately, these can be tough discussions with managers that are passionate about particular projects.  I addressed the situation by seeking references with experience in the same type of project as well as defining the resource and activity requirements up front.

 In my experience, poor governance can really be a pain and may lead to additional work and rework.  I’ve been working on a project that several of the key stakeholders have not been that active throughout the project.  Now that we’re nearing the completion of our RFP process, these stakeholders have essentially said “time-out” in order for them to catch up on the project to ensure we followed all of the required steps that they failed to give us at the project startup. 

Lastly, I wanted to quickly discuss the environmental changes that impact projects.  I would say that this is the most difficult of the failures to address.  The article suggests (i) making timely decisions, (ii) considering smaller projects, and (iii) managing expectations as possible ways to manage environmental changes.  However, these solutions aren’t always appropriate or may not apply.  I worked on a project last year in which the timeline was based on the FASB/IASB (accounting standards boards) making a determination on a change before year-end.  The board’s timeline was pushed out for another year or two which ultimately killed my project.

What projects have you worked on in which the environment changed and what happened?

http://www.mindtools.com/pages/article/newPPM_58.htm

Doing some further reading on project management, I stumbled across the article “Learning from Lessons Learned”, by Kam Jugdev.  I thought this was a very interesting article and excellent as the subject of this blog, because it talks about closing a project and learning from its mistakes, something we touched on in class.  The article agrees with Professor Cook’s statement, that this is something that most companies neglect to do, and something that employees resist because they would much rather move on to the next project and put the old project in their rearview mirror. I also found it interesting reading through the rest of the classes blogs that this was something I didn’t see touched on, indicating that it is still a subject that people tend to overlook.

The truth of the matter is though, that for a company going forward, closing and documenting the project is going to be the greatest source of value to the company, because it can have an impact on a wide variety of projects in the future.  Jugdev points out that knowledge based assets many times provide firms with their greatest competitive advantage, and by learning from prior projects companies are achieving economies of learning, and also creating a competitive advantage because each companies project experiences are unique and difficult to imitate. Companies that fail to properly review and document their projects are thus passing up a great chance to enhance their competitive advantage in their industry.

I work in Finance and don’t have any project management experience, but even in Finance I see the benefits of proper documentation. Whenever we have a new process or journal entry, we document it thoroughly and put it in what we refer to as our documentation “Bible”. This has been incredibly useful for us because we have had a lot of turnover in the past year, and not all duties have a proper back-up.  Without this documentation, the knowledge of many of our processes would be out the door along with the exiting employee.

My company is basically a project management company – we handle projects and rollouts for big retailers such as Wal*Mart, Kmart, and Target among others.  Documenting and closing projects has not been adopted as a common practice in our company, and the negative effects of this have been apparent over the last year.  During a big project for FSG Energy, our PM’s made the same mistake that had been made in a project for Walgreens several years ago, causing a huge loss on a $2 million project.  Of course the PM’s who worked the Walgreens project are no longer with the company, and with no documentation this situation was bound to happen again.

Jugdev’s conclusion in his article is that while it is extremely important and has a significant impact on the bottom line, a formal process for closing a project has not yet been widely adopted in industry.  My question would be, does anyone work for a company that does have a formal process for closing projects, or does anybody have an experience like the one described above where a company repeated previous mistakes because they didn’t have proper documentation?

In the two class periods that we have meet, we have talked about multiple issues that come up during a project.  We have talked about hard deadlines, contracts, contractor/client relations and so on.  One aspect that has not really been talked about and it might be one of the most important aspects of project management is ethics and ethical issues in project management.

I found an article, “Ethical Issues in Project Management” that discusses some ethical situation that might come up during a project and that a project manager might have to address.  The article focus is on three possible situations that could affect a project team and the ethics involved.  The following is discussed in the article: admission of wrongdoing, focus of blame, and hard choices regarding contracts.

The first ethical issue the article discusses is “admission of wrongdoing”.  Admission of wrongdoing can sometimes be the hardest thing to for a person to do.  When a project does not go well or issues arise during a project, a project manager has the dilemma of having to admit and take responsibility for what went wrong.  According to the article, ethically, if the project manager is at fault for the unsuccessful venture of project completion, then that project manager must be able to admit this wrong. Not admitting wrongdoing can greatly damage the team relationship.  Have you ever been a lead on a project or member of a project team were the admission of wrongdoing became an issue?

The second ethical issue the article discusses is “focus of blame”.   As we all know it is easier to blame someone else when something does not go right then to take the blame ourselves.  This is also true for project managers.   The article states that ethically, no one person should be singled out if a project fails unless it is the project manager.  The project manager is in charged of getting the project completed.   Sometimes a task can fail despite the project manager’s best efforts.  If this is the case, ethically, the team should take responsibility for the failure and not one or two individuals.  Have you ever been part of a team and the lead tried to blame you for the failures of the project?  Have you ever tried to blame someone else on your team for a project failure?

The last ethical issue the article discusses is “hard choices regarding contracts”.   Contract may have clauses built into them that may violate ethical beliefs and values.   The article gives the following as an example: a defense contract may stipulate that members of a project team cannot be of a certain race or origin to qualify to work on a project. Is this ethical or unethical? The answer may be debatable. To some, this is ethical in order to ensure the protection of the country’s top-secret initiatives and projects. To others, however, this would be an example of discrimination based on race or ethnicity and labeled unethical.  The question I have is with all of the technology and resources that are available today to do background checks, is it still ok to discriminate for any reason?

Source: http://www.brighthub.com/office/project-management/articles/53025.aspx

We’ve spent significant time discussing project proposals, project selection, project management tradeoffs (scope, cost, and time), and, to a limited degree, team selection.  Ideally, a project manager would have input into these aspects before leading a project.   However, that isn’t always the case.  I’ve been fortunate in my career to participate in and lead several significant projects, but I want to talk about one of my career’s biggest challenges.  I joined a company and assumed the role of project manager for a project that had been in progress for several months.  My new company was also in an industry that was outside of my expertise.

The specific challenges I faced were budget constraints, time constraints, and project resources that I inherited.  Because I was in a new industry, I was also speaking a different language when it came to products, processes, and jargon.  These were unfortunate circumstances, but they were no excuse for project failure.  I needed to make sure the project was successful, and I quickly learned two key lessons:   rely on the expertise of your team members and focus on your project management skills and relevant experience.

The first thing I realized was that I had let myself get bogged down in the details in the past.  It would‘ve been beneficial to have a great understanding of the business and products, but, in the past, I could lose focus of driving the overall project.  In my new situation, it was almost impossible for me to micromanage because I simply didn’t have the specific knowledge to do so.  This kept me focused on the overall project in terms of facilitating discussions, assigning tasks, and meeting deadlines.  The project team members were very bright and had a significant amount of experience in the industry, and the consultants on the project were capable of providing guidance in terms of best practices.  Letting go a little bit to let the experts focus on the best solutions was a big step for me, and it helped reach optimal solutions and helped the project progress according to the timeline.

Because I didn’t have industry knowledge, I needed to focus on my project management skills and applicable experience.  As I said above, I began to focus on the big picture and on ensuring that my team members knew what was expected of them in terms of deliverables and timelines.  I also focused on my experience of working with and implementing supply chain systems and processes.  I made up for my lack of experience in the specific industry with my significant experience in demand planning and operations.  Even though I could not provide a lot of insight regarding the specific products, I knew what it would take to build a collaborative relationship between the sales and supply chain planning teams to improve our inventory turns and fill rates and to complete a successful project.

I am curious if anyone else has had a similar experience and whether you share my views or have had different takeaways.

I read an article from Project Times that focused on escalation when work is not being completed.  In many environments and project structures, those doing portions of the work on the project are not likely to report directly to the project manager.  Oftentimes, these people may be on multiple projects or if a standard employee in a company, might not normally have project based work at all.  The article looks at what you can do when the work that needs to be done for your project isn’t getting done and the steps for moving above the person to force progress.

The three steps given in the article are:

1. Determine the impact
2. Discuss the situation and impact with the team
3. Escalate

The idea is to first determine how significant the impact is and gather concrete examples, discuss the situation with the under performing member and see if the situation can be corrected, if not correctable, inform the employee you will be escalating to their manager, and finally escalate to the manager.

The article goes over the fact that oftentimes, it isn’t a situation of an employee being unwilling to complete work given to them but rather the simple fact that they’ve been given too much and just don’t have the time to get to your project.  Options that are offered up are redefining their workload, bringing in someone else, or other options that can free them up like transferring other work they’re responsible for.

The article finishes by listing rules for escalating:

• Business policy is primary, then project policy.
• Only discuss the problem, not the person.
• No surprises: Notify those involved as to your next steps.
• Notify your management before you escalate to a team members manager.
• Document your examples, conversations, and resulting commitments.

I think this article gives a fairly concise look at ideal resolution process for when work isn’t getting done within a project in most cases where people involved are known to each other.  However, I do feel it is lacking in that it ignores situations where people don’t have normal contact as in situations where people are located states or even countries apart and only marginally connected to a project.  I believe in situations where say a legal team is needed to sign off on a project, it may be best to move right to top down pressure if possible.  While a clear line of communication likely exists between your manager and yourself, and your manager’s manager, it is possible no strong communication exists between yourself and the legal team.  For the legal team, a minor contract revue may be far down their list, and repeated attempts at discussions and emails are likely to not product any effects.  Direct communication up your chain, and the cross communication at a higher level to produce quick results may be easier and more effective.  As with most things of course, each situation is unique.

http://www.projecttimes.com/articles/getting-the-most-from-your-project-staff.html