Search News Articles

When Project Plans Go Awry

Note: this is a reprint of an article originally posted on articlebase.com on March 28, 2013. The original article can be found here.

By Cassie Woolworth


In the past few years, with Demystified IT, I have been able to peek inside many projects and project plans to review what has gone right and what has gone wrong - projects that may or may-not-have worked according to plan (or no plan). I have also reviewed quite a lot of good intentioned plans - where the force behind the change knew exactly what they wanted and where they wanted to go they just couldn't figure out how to get there.

There are typically five players in all IT development the Business Owner/ Sponsor, the Business Analyst (BA), Project Manager (PM), Solutions Architect (SA) and the Q&A Tester (Q&A). In each and every case, communication is the primary problem.

For example, let's start with a Simple (or not) Project.

Starting with the Business Owner - in this case, he sells ice cream. He has decided he wants to start offering free toppings based upon what the customer purchases. Sprinkles will be added to all one-scoop sales, fudge/liquid toppings to all 2-scoop and for all 3 and above, they will get both toppings for free. We will call this the 1-2-3 Project.

The BA puts together a Requirements Document on the 1-2-3 model.

The BA documents the overview, the design, the way the register should work, the business specifications and budget impacts as well as Use Cases.The BA then brings in the PM and the SA. They all review the Requirements Document and then write Project and Technical Specifications and structure a timeline 10-weeks.

The BA sends this information to the Business Owner, he signs off and is very excited - in 10 weeks, they have their annual Ice Cream Show in Chicago and Marketing can start promoting the new 'freebies' now.

The SA starts assigning code to programmers. The PM is reviewing the schedule and making sure timelines are met. The programmers are coding and all looks well. Then, Cherries happen.

The SA asks the BA if Cherries were ever covered in the Business Specification. The BA looks as the spec, and says no, not covered. The BA is going to have to check with the Business Owner. Programming proceeds.

A week later, the BA tells the SA that cherries were never included in the freebies. The SA puts a 'cherries' change in with the programming, assigns a coder (who is currently working on the 1-2-3 Project) to work on this issue as well. Coding continues.

Then whipped cream happens. The coder assigned cherries starts thinking about putting in a routine for all additional items - he decides that cherries, whipped-crme, nuts, extra fudge and banana's would not add much time to the coding. He starts working on the routine for these additional costs. The Programming Unit starts missing the deadlines but is still making progress so all is well. The PM/BA did put a little wiggle room in the schedule.

At about 7 weeks the Q&A department notices that the 1-2-3 Project is slated to be in Q&A the following week. They ask the PM if the code will be ready. The PM has seen a decline in hitting timelines and deadlines, but believes they will be ready to test the following week and says yes. The PM then goes to discuss the timeline with the SA.

The SA has just gotten done with an IT meeting with all coders on the 1-2-3 Project. They are 2 weeks behind. He has spoken to the coder who has the cherries change and learned the coder also coded for nuts, whipped crme, etc. and has not had a chance to finish the original 1-2-3 coding. But, the coder states, his cherries are functioning perfectly! And they only took 4 days to code!

In the meeting between the SA and the PM, the SA tells the PM that adding the cherries was a big hit to the timeline effectively leaving them 2-weeks behind. The PM asks "What Cherries?" The SA explains that the Business Owner stated that he had to have the cherries, and that coding is complete - but the original 1-2-3 coding is delayed.

The PM states that the SA must have the coding done in a week if they are going to test. The SA states that he can see if they can code faster. The PM then goes back to Q&A and lets them know they will get the code in 2 weeks, not one. Q&A will only have one week for testing prior to launch.

At week 8, the SA has a meeting with all coders. At this meeting he is ready to pull the project pieces together, ready or not, and work through compiling. The coders start trying to assemble the code but notice right away that the coding methods do not match up - some coders put together the routine 1=sprinkles, 2=liquid and 3=sprinkles and liquid; others put together the routine 1=sprinkles, 2=liquid and 3=1+2.

At week 9, the SA is forcing the code into place; adding lines of code stating "3=ALL".At week 9 the Q&A team is testing and stating that it is unrealistic to go live at 10 weeks.

At week 10 the SA rolls the product out to production, against the Q&A teams wishes, with the blessing of the Business Owner.At the Ice Cream Show in Chicago the Business Owner is confused as the new software doesn't function correctly, is very buggy and nothing is free.

At week 11 the Ice Cream stores can't operate with the new software. The little training they had included a bunch of 'work-around's' which are not documented.

At week 12, the Business Owner makes an executive decision to shelve the 1-2-3 Project and return to the last good software.

What this example exposes is that all of the issues above could have been solved with communication.

Projects are supposed to be linear. Someone has an idea and the Project Team is charged with carrying out this idea. Should be something like this:

Decide->Discuss->Design->Document-> Code->Test->Repair->Test->Launch

Communication can be in the form of a meeting, webinar, video, documentation, specification, mock-up, data scheme, drawing or any other tangible item that is available to all who work on a project. But all of this communication this documentation - does no good if no one is using it.

With the example above:
  • The communication from the Business Owner to the BA was ok, but the BA needed to delve further finding "Cherries".
  • The PM, charged with running the project, was left out of the loop when cherries were introduced. He continued with the timeline objectives not knowing the impact.
  • The SA did not clearly state to the coder that Cherries were not allowed to impact the timeline.
  • The Q&A people did not get the information that the programmers were behind. Actually, testing could not even begin until Week 11.
The only one without fault is the Business Owner as he stated what he wanted, not how long it should take. (By-the-way, some Business Owners do state timelines that is another conversation on what you CAN have vs. what you WANT to have or as I like to call it "The 27-Hour Work Day").

To fix the Communication problem, all it takes is defining the linear component Who Impacts What? AND Who Gets a Say?

For example, when Cherries were discovered both the PM and BA should have been notified. Once the business Owner was consulted, the PM could write a Change Order or Addendum letting the Business Owner know that more time would be necessary.

When the SA got the approved Change Order, he could have told the coder they had extra time for cherries ONLY.

When the coder found whipped cream he tells the SA, who tells the PM and BA, who then bring it to the attention of the Business Owner. Each one informed at every step.

It would be entirely possible that the whipped cream and nuts problem may have even been addressed on the Cherries Change Order - another thing that happens when you keep all the people in the loop. Heck - the Business Owner may have even requested more resources in order to finish at 10 weeks.

In any case, the Business Owner would have had all the information available to make sound decisions; and keep his Companies reputation.

Ok, so what to do...

First of Document. When starting a project, ensure you have all the information. Document everything, even silly things will come back to haunt you. Meetings, notes, email's, suggestions, meeting minutes, bad and good ideas every last line item, document the heck out of it.

Invite people to assist in defining requirements even if they won't be involved in the project send it to your apartment manager, your auto-mechanic, heck, send it to your Grandmother. I have gotten great advice and insight from non-impacted people. Sometimes these people REALLY think outside the box.

Write a Requirements Document from all of the information gained in the processes above. Re-read it, pass it around make sure you have everything that is possible to know. Map out and stated all items and issues in this master Project Document. Sure, there will be other things as time goes by, but, as they say, an ounce of prevention...

Next, make it ALL available not just the Requirements Document, but all of it. Store it on a server. Make only ONE copy of everything. Sometimes re-reading old ideas tells us why we didn't include it in the first place. If anything impacts your project put it in the Requirements Document even if you have to list it as a side note. If you do this well, you will also have a great start to the User Test Cases.

Next take the Requirements Document and detail it. Make it as fine and detailed as you can in order to put accurate hours to each and every step. The PM and SA must be involved in this process as you will be producing Project Specifications as well as Technical Specifications. If you document this stage well, you will actually produce User Test Cases.After the specifications have been written, now it is time to slate a timeline. First off, how many resources do you need? How many are available? How much work can they get done in a day? Will holidays or vacations impact your schedule? Once you have all of this covered, and an accurate timeline, send it up to the Business Owner to sign off on. You will notice not one line of code has been written yet.

After sign-off, gather the troops (BA/PM/SA and coders) and Assign the Elephant. Within a project, one of the worst things you can do is have coders who check-in and out code and never know how the elephant goes together; Here, Trevor, you get the tail; Chris, you get the front left foot; Ethan, you are best with core coding so you get the body. If they do not know it is an elephant they typically come back with a donkey tail, dog's right foot and hippo's body. Similar to our 1-2-3 coding above where 3= 1+2 AND 3=sprinkles and liquid.

Ok, then more documenting. Who is in or out-to-lunch; who is making their timeline; who is vacationing. Updates weekly/daily or hourly whatever is necessary. The PM and SA need detailed information, the BA and Business Owner need a broad overview and the coders need a more detailed account than all others.

The reason for this oversight is simply to control your timeline and budget but the bigger picture is to keep everything moving so that other departments are not impacted by your delays/changes. The Q&A Testers have a limited amount of resources as do the hardware guys they all need scheduled.

Once the coding is finished never, never ever, scrimp on Q&A testing. Even if it holds a project up from distribution just test it. Unless you are Microsoft (and if you are Microsoft you have the ability to launch a sub-par software with Service Pack1 right around the corner) test, debug and test again. Now you are ready for roll-out.

Many of the projects I have been brought in to 'correct' have the same communication issues - from the plan that was started prior to documentation to the plan that started as a widget but ended up being a band of widgets with whistles and drums. The thing they all have in coming is the lack of communication.

Good communication can make the daily issues less important, keep the managers informed, schedule other departments for timely assistance, and keep the finger-pointing and excuses to a minimum, but the best reason to communicate is to keep your job. If you document, the finger can never point at you.

In The News is brought to you by WinMill Software, the premier resource for systems development and integration, expert consulting, quality assurance, technology infrastructure, and software resale. For more information, contact a WinMill Account Manager at inquiry@winmill.com or 1-888-711-MILL (6455).