When Projects Go Sour

PDFPrintE-mail

It’s happened to all of us who have consulted. We start a project with appropriate planning, and then something happens and it seems that nothing is working anymore. Budgets and timelines have gone out the window, the client is upset, and we are in recovery mode. Without pointing fingers, here are some of the reasons that projects go astray.

  1. The scope is not well-defined. Especially with what are perceived as smaller projects, it is easy just to say, “Create these reports,” or, “Create an interface from this system into that one. “The specific requirements are not written out or reviewed with the user. The user thinks he or she is getting something that looks like A, and the consultant is sure that the requirement is for B. The consultant thinks the requirement is simple, and the user and the consultant don’t communicate very well.
  2. The scope expands and the change control process has not been considered carefully.
  3. We didn’t create, monitor, update, or follow the project plan. Project plans are an integral part of a successful project. The more detail in the plan, the better the estimate is. Creating good project plans is a real skill, but there is a lot of art involved too. For those of us experienced in creating project plans, there are red flags in our heads that show up when something is not as we expected from our experience on other projects. These early warning signs are good indicators that it is time to review and update the project plan.
  4. The scope is well documented, we have followed a strict change control process, and we have a plan, but it is a project that we have not done before, so we grossly underestimated the level of effort and resources required.
Take the case of the project that was estimated at $100,000. The consultant prepared the estimate, submitted it to the client, and the client accepted the proposal. A couple of months into the project, the consultant realized that the project was much more complex than anticipated and would cost 5 to 10 times as much as estimated. Three things tend to happen in that case. The first is that he continues the project, and when the $100K has been spent, nothing works. The client is unhappy but figures that by throwing a little more money to the consultant, everything will be fixed, so the project drags on. The client just keeps throwing good money after the bad. The second thing that happens is that the consultant points a lot of fingers and says that the users didn’t really communicate the requirements clearly or that something has changed. He then fills out a change control form for a huge amount of additional money. Sometimes the client buys into this, but often the entire project is abandoned. In a third scenario, the client decides to engage a different consulting firm. However, when the new consulting firm comes in, the client’s expectation is that they have already spent $100K on the project, so the remaining work is minimal and they don’t want to go back and confess that the first consultant made a mistake. After all, it was the client who signed off on the initial consultant’s proposal in the first place, so maybe it is just as much the client’s fault as it is the consultant’s.

How do you avoid this mess? The secret to a successful project is great documentation.

Documenting the requirements, documenting all assumptions, documenting the discussion items and issues around the requirements, documenting deviations from the scope or the project plan, documenting the basis for each line of the estimate, and documenting each decision that was made and the impact of that decision, along with documenting all the procedures, processes and all aspects of the build or implementation allows you and the client to closely monitor progress and provides early warnings when something is not as expected. With proper documentation it is easy to turn a project around before it is in trouble.

Add comment


Security code
Refresh

Email Newsletter icon, E-mail Newsletter icon, Email List icon, E-mail List icon Enter your email address to sign up for our Newsletter

Sign up now

captcha
TEChanges - Agility by Design

May Puzzle

David is often referred to as Rainman due to his peculiar ability to effortlessly figure out a certain date's day of the week. He recently displayed this talent when I asked him if there was a conflict with the upcoming Fuzzy Dice Conference and our weekly court-ordered community service. He asked the date of the convention. It was April 20th, 2012.

"Oh, that’s a Friday," he said, effortlessly. "And your sentences have you committed for the next few dozen Wednesdays so you'll be able to go." And of course he was right.

One day a few weeks ago I asked out loud in the office about the date June 5th. And of all people, my brother Tommy piped up and said "Oh, that's a Tuesday."

"That's right," said David.

Well how about Otcober 3rd?

"That's a Wednesday," said Tommy. Then I asked about Christmas Day 2012.

"Oh, that's a Tuesday." David nodded in agreement.

Do we now have two rainmen? Or had Tommy figured something out?

Show solution...

Solution

Here's what was going on. Tommy was using something called anchor dates. And these dates apply to each and every year. April 4th, or 4/4 we’ll call it from now on, June 6th or 6/6, 8/8, 10/10, 12/12, are all the same day of the week, each and every year.

So too are 5/9 and 9/5, May 9th and September 5th. So too are 7/11 and 11/7, and all the above dates are the same day of the week, as is the last day in February, Leap Year or not. And they’re all the same day as January 4th, it would otherwise be January 3rd, but this was a leap year, and that’s changes the anchor day from January 3rd to January 4th.

Tommy also knew that New Year's Day was a Sunday. He was sobered up by then. And he knew it was a Sunday because Christmas was a Sunday in 2011, so New Year's Day is a Sunday, so the Anchor Day for 2012, January 4th, has to be a Wednesday!

So if that's a Wednesday, then 4/4, 6/6, 8/8, 10/10, 12/12, 5/9, 9/5, 7/11, 11/7, and February 29th are all the same day of the week, and they're all Wednesdays. So when I ask for example, about October 3rd, he knew October 10th was a Wednesday, 10/10. So 10/3 must also be a Wednesday. 12/12 is a Wednesday in 2012, so it’s 12/26, which is two weeks later. So 12/25, or Christmas Day, must be a Tuesday.

Success Tips for Oracle Project Management

  • Create a standard for documentation at the beginning of your project, and hold team members accountable for completing documentation requirements as well as keeping them at and above the standards required.
  • Before promulgating user documentation or training, it’s also a good idea to choose a representative from the among the business users base to review materials first.
  • If you are not sure about the resources and budget required, obtain several estimates from people that have experience with the same size and scope of your project.
  • Be explicit, before beginning the project, what internal resources are required for execution. This includes people, infrastructure, hardware, and software.
  • Help the project champion understand the impact your project will have on the organization and how its successful completion will make him or her an internal hero or heroine for supporting it.
  • Break up your project into smaller projects (try for projects that can be completed in 4-6 months, especially early on) to get success and demonstrate momentum.
  • Make sure that your testing includes reports, upstream and downstream interfaces, customizations, enhancements, and workflows.
  • Ensure that comprehensive transition reports and meetings between departing and incoming personnel are completed.
  • Instead of spending time and resources implementing third-party reporting, consider consolidating multiple instances, moving to a global chart of accounts (CoA), and/or standardizing on a consistent calendar.
  • Include governance, risk, and compliance management as part of the project plan.
  • Finally, celebrate the successes. Too many projects focus on defects, failures, or small cost over-runs without looking at the big picture and what was accomplished.

The Analyst Corner

John Van Decker, Research VP of Gartner, states:

"A single chart of accounts allows consistency in financial reporting across the enterprise by standardizing on common metrics and reporting structures, reduces dependencies on a separate financial consolidation system, and significantly reduces the costs incurred with ongoing, complex conversions and translations."