Do you think it’s easier to start a new project, or to take over a project someone has already started?  Sometimes it seems as if the same projects get recycled multiple times until the project is successful.  This may be due to several factors, which have already been blogged about.  I think that many times individuals are more hesitant to get started with an already failed project and are more open to starting from scratch on a new project.  However, I remember a discussion in my MIS500 class where we talked about this same topic in relation to IT implementations, and I remember the professor commenting that if you are asked to take over a project, you are already successful because the project has already failed.  I think if I had to choose, I would take on an existing project rather than starting a new project.  First, I would welcome the challenge to learn from the previous group what went wrong, and I would aim at small wins to build the trust in the new project team.  I say this because sometimes starting a new project is difficult, as is highlighted in the article “The Paralysis of Getting the Project Started”.

This article highlights a few steps that one might find useful in getting a new project started.  Even though he doesn’t include this as a separate section, the author points out something that I think is critical in project management.  This is the realization that once you get started, it is not realistic to expect that everything will be perfect, or that it will be perfect as you continue through the project.  What the author does provide us with are the 3 steps to get a project off the ground:

• Grab a template that has worked well in the past for you or another group, and one that you feel comfortable with.  In this step it is important to realize that it will change along the way.  In our class we learned about several great tools that we can use, but I think the key here is finding a tool you are comfortable with, which goes back to the small win concept and provides you with immediate confidence, which could be a large struggle that individuals have because they think that for a successful end there needs to be a successful start, but this means that nothing from start to finish is flexible, when in reality a successful project management plan is flexible.
• Realize and explain to the team that it is impossible to know all the information about the project up front, so stick to the basics and move forward.  Often times many projects are delayed because the project manager wants to know and plan for every detail but if this is your focus, it is impossible to ever be ready!  Again here is an important link to flexibility…
• You may be the project manager, but you need to be willing to let your team help.  This may take the form of brainstorming with post its to gather input on the best way to get started, or by taking your initial plan and sending it to them for review.  Either way, its important to involve the team early on to ensure you have their buy-in and being an inclusive project manager will go a long way to making the team feel connected and supported, which in turn sprouts ownership and helps to ensure that a project stays on track for success.

In project management there are lots of discussions around the management of scope and budget for a successful project.  I was reading an article around embracing the twists and turns in project management, and I thought back to our class project with marshmallows and spaghetti.  The winning team may not have used their entire budget but still had the best outcome of the class, so was that a successful project?  Can a project still be successful if we allow for uncertainties that arise during the project?

The article discussed how risks or uncertainties that arise are often viewed as setbacks to a project, but some project managers fail to see them as a potential for opportunity.  The article identified four categories of potential opportunity; Technical Innovation, Implementation Processes, New business and Value beyond the initial scale.  In addition, it covered 6 primary types of uncertainty; Contextual Turbulence, Stakeholder Fluctuations, technological Uncertainty, Project Uncertainty, Organizational Uncertainty, and Malpractice.

I’m currently engaged in an Oracle ERP upgraded, which is being overseen by an ePMO but implemented by different functions, and I have the HR module.  The scope of the project is to get the full organization aligned with one global ERP.  The HR function was the original adopter of Oracle and was on an outdated system so to get to the common platform we anticipated having to go through 2 upgrades, one to stabilize and meet the company on a common platform and the 2^nd to move to Oracle Fusion to deliver the needed functionality.  After the initial move and utilization of the system an uncertainty popped up around process and functionality, and since we were implementing plain vanilla out of the box we saw an issue where the system no longer supported us in the customized way in which we were used to operating.  Instead of moving forward with the next phase, we decided to take a step back and map our processes to fit the system, instead of the other way around.  Since we didn’t know the new system this was unexpected for us, which resulted in being behind schedule but under budget and without pain points that other functions are feeling.