Avoiding Headaches for Projects?


I found this cartoon had a clever and funny way to depict the stages of a project.  In thinking back to our class activities and assignments, including this past week (Project Network with Post-Its, Identifying Critical Path with Rock ‘N Bands), it is proven that there is more than one way to think about the same project. Can we take the questions from the cartoon and relate them to the class so far?

Will it work?  For the sake of discussion, let’s assume “it” is a project itself.  Asking a question about whether a project will work or not begins with knowing what the project is and defining how you know it worked.  This sounds similar to the Request for Idea and Implementation Plan assignments.  In class, we learned it is important to know what the measures of success are in order to understand if the plan was completed accordingly, and to consider project scope at all times.

What if it doesn’t?  When the project does not go as planned, is there something to do?  After the Implementation Plan is set, the next step we learned is to consider what happens when something does not go as planned.  The question begins with “What if,” which is a perfect way to think about risks in a project.  There can be a long list of “What if” statements, but identifying these risks was part of the assignment of the Risk Analysis.  It was also important to discuss the contingency plans for when “it doesn’t” work.

Who can we blame?  This particular question seems harsh at first, but consider more of the class assignments and the reason for them.  We have heard a few times that “if ‘team’ is assigned to a task, then no one will do it.”  The Work Breakdown Structure was completed for the purpose of knowing which team member would work on a task, and subsequently, who to follow-up with.  It would be inappropriate per the cartoon to blame one team member or other source for the entire success of a project, but it should not be taken lightly either the impact one member can have on the rest of the group.

Can you keep a secret?  Following the preceding question, the cartoon wants to suggest to keep any failures of the project a secret.  This question may have been better phrased as “do you want to keep a secret?”  The intent of the projects in class is to learn about project management through our successes and provide insight on what we can improve upon.  It is important to provide a focused summary of how the project was completed, so by omission there may be some “secrets” on the blog.  Overall, it is best to share with the class about what worked and what did not.

What do these questions mean to you?  Did you find a different way to relate them to our class assignments or activities?


Risk, Risk, Risk, Can you avoid it? Can you plan it?

I came across an article that talks about managing risk on our projects.  Brad Egeland, who is the author of the article implies that the risk can be mitigated by dedicating a chunk of the project money to the risk.  He also points out that, there are times where we create a risk management plan but don’t follow through with it due to time or budget constraints.  I totally agree with Egeland that well documented risk management process is always going to be a great strategy to follow.  What happens when you don’t have enough money to asses or plan for risk?  Do projects without any budget assigned to risk fail?

In class we have learned that, to manage risk we must proactively attempt to recognize and manage internal events and external threats that could potentially affect the project.  One of the most asked questions on the project is “What could go wrong?”.  Many times we are uncertain of the consequences of our actions until they are completed.  There are times where we can sit down and really ponder about the situation that could potentially put the project at risk.  Usually ideas that put a project at risk are put on the side and quickly forgotten.  Risk management teaches us to be more proactive than reactive.  I think everyone can agree that being proactive could potentially eliminate most of the risks from the project unless we experience unforeseen risks.  At that moment we better have some kind of a contingency plan that will reduce the negative impact of a risk event.  Contingency plan will usually require some kind of a budget.  Depending on the project, the risk assessments could identify additional budget requirements or reserves as some might call them.

Many times I jump into a project without thoroughly assessing the situation for risk.  Risk is not something that we think about everyday.  Most of us usually react to the situation and are not proactively estimating the potential risk.  Once the problem arises, I personally document what went wrong.  I start from the beginning and trace all my steps to find out how,why and where did this go south.  Once I have determined the root cause of the problem I am more inclined not to make the same mistake twice.  The reason many of us jump into the project without looking at the risks is because risk planning takes long time and sometimes is unavoidable.  Some might argue that risk planning should depend on the size of the project.  I would strongly recommend that even a small project should have some kind of a risk assessment.  At the end of the day don’t we all want to be perfect?

If you would like to read more about managing risk on our projects please feel free to read Brads article.  The article could be found at http://blog.aecsoftware.com/2015/04/are-we-really-managing-risk-on-our-projects/

Project Risk Identification for New Project Manager

Rajman Md Rawi on his article “Project Risk Identification for New Project Manager” for PM Times gives us a few tips to identify risks as a project manager.

It starts the article with a very clear definition of Project Risk Management, taken from the book Project Management Institute. A Guide to the Project Management Body of Knowledge “Project Risk Management includes the processes of conducting risk management planning, identification, analysis, response planning, and controlling risk on a project. The objectives of project risk management are to increase the likelihood and impact of positive events, and decrease the likelihood and impact of negative events in the project.”

Then Rawi gives us a few tools/techniques to identify risks like: Documentation Reviews, Information Gathering Techniques – Brainstorming, Delphi Technique, Interviewing, Root cause analysis, Checklist analysis – previous similar project, lowest level RBS, Assumption analysis, Diagramming Techniques – cause and effect diagram, system and process flow chart, influence diagrams, SWOT Analysis and Expert Judgment.

He also gives us 5 categories of potential risk that a project could be exposed: Human Resources & Contractors Risk, Customer Risk, Product/Technology Risk, Requirement Risk, Schedule Risk.

Schedule Risk, he advise us to be aware when our schedule is not realistic,  we have a missing task in the schedule, we don’t take on account a potential delay in one task that could delay other tasks in the future, and unfamiliar areas of the product that could take more time that initially though due design and implementation.

Requirement Risk, he recommend to be alert to continuing changes in requirements, requirements poorly defined, some areas of the product could be more time-consuming than others, we are only aware of some requirements when the project start, and total features could be more than what the development team can deliver at the time.

Project Management Risk, he mention that the project manager could have little authority in the organization and low power to influence decision-making and resources, priorities change during the project, we have to clearly defined evaluation criteria for every project phase, we have to be aware that multiple projects within the same company could need the same resources at the same time. And that sometimes the date is driven by marketing demo, tradeshows or other events and not been taking under consideration project teams estimates

Product/Technology Risk, we have to be vigilant that development of the wrong user interface, application or program could result in redesign and implementation errors. Development of extra software functions that are not required could extend the schedule. You could depend in technology that is still under development. And the technology selected could be a problem to the customer

Customer Risk, customer could insist on new requirements or other technical decision, Customer review/decision cycles for plans, prototypes, and specifications could be slower than expected. Even if you product meets all specifications, the customer could not accept the product. And Customer has expectations for development speed that developers cannot meet.

Human Resources & Contractors Risk, Critical development work is being performed by one developer, some developers or contract personnel may leave the project before it is finished, hiring process takes longer than expected, Personnel need extra time to learn unfamiliar software tools, hardware and programming language, there could be conflicts among team members result in poor communication, poor designs, interface errors and extra rework. When looking for new personnel, there is a risk that you cannot find someone with critical skills needed. And contractor could not deliver components when promised.

I agree with his conclusion, I also think that in order to manage and successfully complete a project we have to be able to identify risks and have to be proactive to mitigate the negative impacts that those risks could have, and make a routine out of identifying risk because as he explains, risk can be change throughout the project and vary their importance.  The only statement that I disagree is “we should not spend too much time in identifying risks”. Even though it could be time consuming I think that, you should spend time identifying risks to mitigate future negative outcomes.


PMBOK; 2013 ; Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Fifth Edition
Donna Ritter; 2013; Identifying Risks in Your Project. Retrieved 15 December 2013, available fromhttp://certifedpmp.wordpress.com/2008/10/13/identifying-risks-in-your-project/

Article: http://www.projecttimes.com/articles/project-risk-identification-for-new-project-manager.htm

Stop What You’re Doing. Read My Blog Post on Risk.

Over the course of my career, I have witnessed many projects.  I run sales for one of my company’s divisions.  If our sales group wins an application, it gets moved to program management/engineering group for execution.  The sales team is aware of the project, gets status, details, etc., but is not a true team member of the project.  Our sales group has a stake in the success of the project, because our customer won’t be willing to speak with me again if the project is a disaster.

So, all these projects have occurred, and I have had my fair share of disasters.  One very important piece of the program management pie is RISK.  Yes, risk identification and mitigation; what some may call the most boring part of a project.  The exclusion of this boring process has also led to me having very difficult conversations with customers.  So boring or not, stop what you are doing and make sure you go through risk identification/mitigation on your next project.  I don’t want to be yelled at anymore.  Help me, help you.

Here are some things that will help.

Know Thy Project – I have often seen projects go through risk identification and mitigation, only to get burned up on schedule and cost by an adjacent risk that nobody ever thought about.  This is due to rushing through project planning to start development.  BIG MISTAKE.  SIPOC is a great acronym to utilize at project onset.  It stands for Suppliers/Inputs/Process/Outputs/Customers.  It also helps with risk identification.  By utilizing SIPOC, the risk of not identifying risks is mitigated!  You’re welcome.  The following link explains SIPOC and how to utilize it: http://www.discover6sigma.org/post/2007/06/sipoc/.

Alright, great, we are now confident that risks have been fully identified because we looked at Risk through the SIPOC lens.  Now, it is important to have a Risk Register developed before beginning project execution.  Jumping the gun and moving to project tasks always seems to be the Achilles Heel of a project.  Risk Register’s avoid disaster.  There are many ways to develop risk register’s.  I found this link to have a good explanation and guide: http://hse.ie/eng/About/Who/OQR010_20090422_v_11Developing_and_populating_a_Risk_Register_BPG.pdf

The guide was based on health service industry, but the risk development process is solid; which would be expected considering the industry.  On page 5 and 6 of the above link, there is a really good visual for creating your project’s risk register.  The pages that follow provide guidelines for gathering risk and is similar to SIPOC.

Lastly, once a risk register is developed, and developed based on truly understanding risk, the most important thing to do is utilize the documentation.  I find it odd that project teams go through the risk process and then forget about it.  Bright hub had a nice article on managing risk throughout the project: http://www.brighthubpm.com/risk-management/45164-tips-on-managing-project-risk/

This article reminds PMs that risk registers should be reviewed with the team weekly.  This keeps the information that was so painstakingly developed right in front of the team.

Have you been involved in a project that utilizes these types of risk strategies?  Do you find that these strategies are effective, or, do you have alternate risk strategies that you feel are better?  Risk identification and reduction are often implemented, but overlooked later.  Why does this happen when risk processes are commonly employed at the beginning of a project?

Every Project Manager wants the “best” resource – Resource Planning Issues

In many organizations, its very rare for an employee to be dedicated to only one project. Many times, resources are stretched across several projects demanding their time. And when a new project comes along that is requesting a specific resource who may already be fully allocated, conflict may arise. Often times, project managers of the conflicting projects have project plans with a resource allocation on their individual computers, where no other managers in the organization can view the allocation. Or even worse, the project manager may have never done a resource planning exercise on the project.

In the first article listed below, author Donna Fitzgerald suggests the concept of a centralized project resource allocation system. Not having the centralized scheduling system to show the allocation of all resources potentially puts the projects the current resource is working on as well as future projects requesting his time at risk. By having the system in place, the project manager simply would need to go to the system to determine whether or not a resource could be allocated to the project. If a project manager really wants a specific employee on a project but that resource is overallocated, the manager has two options:  either find another resource (either through another team member or consultant), or push the project start date to another date.

Having a centralized system also requires buy-in from all portions of an organization, which potentially could be a difficult task. However, I feel if an organization were to implement such a solution, it would eliminate a lot of headaches at the resource planning phase of the project. Another potential solution to this type of problem would be to prioritize projects, either at the organizational level, or departmental level, or even at the resource level.

M - Project Manager?
M – Project Manager? Who knew!

In the second article, author Daniel Chou uses the James Bond movie “Casino Royale” and Dame Judi Dench’s character M to illustrate the allocation of various resources (e.g. James Bond) on various projects. In the movie, she manages from the top down, in that she is able to add/remove resources from tasks if a project is getting out of control or if it’s going well. Based on the various risks associated with a project, a manager can accommodate for those risks (hopefully seen in advance through the use of a risk management plan) by adding additional or removing resources at that time.

Does anyone in their current employment situation have a centralized location that shows the allocation of potential project resources? If not, how do you go about ensuring a potential project resource is not overallocated?




World Cup 2014: A good or bad idea for Brazil?


The 2014 World Cup will be hosted by Brazil and faces heavy criticism in regards to event logistics and preparation. The risks associated with hosting this event are great, especially given Brazil’s fragile economic, social and political situations.  Stadium construction has experienced delays, there have been numerous funding questions raised even after the project was well under way and safety issues for visitors have become more prominent as a result of protests and violence in Brazil. All these issues surrounding the event leads me to ask the question: why are these issues being addressed now as opposed to when the project was in its conception stage? Is the fact that Brazil is the most successful soccer nation in the world enough of a reason to ignore all the logistical shortcomings the country faces?

The political, social and economic climate of Brazil has not changed much since Brazil was awarded the rights to host the event back in 2006. Given all the issues surrounding Brazil’s candidacy, why was a such a great risk taken by FIFA? Why not award the event to more infra-structurally solid country so as ti minimize risk? For example, Brazil boasts no public transportation system and an entirely new transit system needs to be conceived in order to accommodate the influx of fans. What if the system is not completed on time? What if it not capable of meeting demand? World Cups in recent times have been hosted by countries (Italy in 1990, USA in 1994, France in 1998, South Korea/Japan in 2002 and Germany in 2006) who have reliable existing systems in place: major stadiums to host matches, solid transportation systems and relatively stronger economies to deal with project funding .  On paper the worthiness of Brazil hosting the event is fair. Realistically, a project like this poses major risks as the prospects for problems arising is great, especially with  the level of uncertainty  facing Brazil internally.

South Africa in 2010 was a unique situation as it was both a economically/socially developing country as well as a soccer developing country. Though awarding the tournament to South Africa had good intentions and was successful, the post-tournament fallout was great. South Africa’s debt was large and many of the stadiums were completely dismantled/significantly downgraded. Further, the spike in economic activity local businesses realized subsided and the impact the tournament had on promoting and developing soccer in the country was lackluster. I would think most projects of this stature would consider the long-term as an essential component of its risk assessment plan, especially given the amount of time and money spent coupled with the country’s internal problems. Since soccer is huge in Brazil,  developing the game there is not a  purpose of the event like it was in previously in South Africa, Korea/Japan and the United States.  I would argue the benefits of hosting the World Cup did not outweigh the costs as the long-term effects of the project were ignored.  In turn, Brazil could face many of the same struggles next summer.