Sunday, October 08, 2006

And the award goes to!

WARNING: extreme rant dead ahead!

I'm about to be totally slammed. By slammed I mean that I will have no social life and spend all my time working on a huge project. My predicament stems from poor planning from the top down. My company has decided to build a brand new warehouse, running it on completely new software, for our purposes we will call if 'LowSquat'. Oh yeah and they also have brought in a completely new piece of software to run all the business functions such as: customer support, order entry, and product data management. Let's call this software 'Magic'!

Magic is not written yet. It's a piece of software which you build 'vertically' to suit your company. Magic's manufacturer licenses business partners to build these 'vertical solutions' (tailored software for client companies). Magic has some great features. It allows us developers to make changes, or create whole new applications that run in it's environment. Thats great and all, but Magic's out of the box the software doesn't do what we need it to do. It comes with a bunch of basic, 'vanilla' applications (like customer service, order entry, and financials). It will be our developers jobs to extend these apps so that they meet our business needs. Fun... So we need to work with this partner to develop Magic's apps/functions, then integrate with the warehouse software (LowSquat), inventory planning software etc. We do this and make sure that this happens right on time (a date that exists only based on construction of the warehouse!).

I wouldn't be so bent out of shape if I trusted the management at my work. Unfortunately they have shown that they do not want to extend themselves. So far I have seen a lot of half measures. Small changes in the way we do things that make little benefit, or that are all talk. One huge obstacle in the project moving forward is that they expect us to already know how the vanilla apps work. Our management's expectations (which do not exist on paper) are going to kill this project. No one knows exactly how all the vanilla apps work. We also do not have the test data set up to properly to 'play' with Magic's vanilla apps. So how do we find out how the unmodified Magic software works? It would be obvious to any project manager that to gather requirements for modifying Magic, you would first need to be very comfortable (dare I say an expert) with Magic.

The software also will be different when we go live. We are using Magic 2.5, but when we go live we will be using a whole new version 3.1!!! 3.1 is completely different in some respects. So why is that a problem? We won't have 3.1 until a month before the projects due for completion. Yikes.

A little background on the project so far. We first worked on a small 'sample' phase of the project. It was one piece of many, and it took damn near 5 months (for me) to complete. The planning for that phase did nothing but cause problems. The milestones/deliverables had dates set that did not rely on any useful information. No one in management bothered to write a full project plan that detailed each feature, how it should work, how all features integrate, how to test each and know it works etcettera. The project was actually just set up by someone with *some* technical experience, so that with dates combined we would hit a certain launch date. This launch date came from above I think. It was bad...one day during a meeting I was given the timetable to complete tasks assigned to me. Laughably, we spent hours going over this completely groundless plan. I could have used that time to do some real work. I don't know how the management felt about the meetings, but they left me frustrated, and I wonder what they got from them.

Another big miss on the 'sample' phase was not communicating across departments. People in departments which should have been involved never knew about our project. We where unaware of how our our project would affect other people's jobs. What happened was I was knee deep in development and finally the word got out what was going to happen. People were unhappy. Last minute, when the project should have been sailing to completion, a bunch of new 'critical' requirements came up. Since time was so short we had to hack together whatever we could. There was no way that we where going to postpone the project launch.

Another real problem I have is that no contact list has been provided. We should have a list of all 'power users' or 'insanely knowledgeable' contacts on each facet of our business. That way I don't have to chase around to find the expert. This allows me to quickly contact a person and get the info I need. We should also have proper training, and facilities to get the training we need. I should not have to wait for 1/2 a day or more to get the email describing what I need.

I guess the above comes to this point: if you don't bother to do a good job, don't expect me to do it for you! By good job I don't mean that you work real hard. I mean you work smart. You know what it is you are doing, and why you are doing it, and why it is a benefit. You communicate those things to other people (on paper!). You look for solutions to problems, problems that you confidently define (on paper!). You face those problems one by one, but all the while keep the big picture in view. Dates that are not created from thoughtful, thorough planning, but from need to hit a date are just a waste of everyones time.

I wish that the management had brought in more experienced people to manage the project. I seriously question the fact that we have total 'greenies' running the show. A project of this caliber requires massive planning. Even I know that and I'm just a low peon of IT. The planning has been lax. They basically drummed up a bunch of 'gaps' and said to me and mine "here you guys figure these out and implement the solution". Great f#*king project management! Now that they have gone through all that hard work to find what the gaps are, I can:

  • Become an expert on the current business functions (much of which I don't know)
  • Become an expert on Magic's business functions, look for gaps :(
  • Compare the 2.5 Magic app to the 3.1 Magic app, find gaps
  • In one month implement all the fixes to the vanilla 3.1 Magic release so that it can run our companies business functions
  • find out if proper functions exist in the new software
  • write business requirements
  • write design requirements
  • Create milestone/deliverables (running tested features?)
  • implement solutions (git' codin)
  • make contact with the users/customers
  • test the solutions
  • write test plans (maybe in my head only)
  • document proper processes
  • document my time and progress
  • Create and set my own goals, milestones and deliverables
  • Manage people on my team
  • More to come


Compound all this work with the following:

  • Create plans to train employees on new software
  • Train the employees on new software
  • Test the fully integrated solution
  • Test the warehouse on the new softwares
  • Collect info on the terrible bugs (don't sweat the small ones ;)
  • Fix the terrible bugs (probably goes in my list above)


There has got to be many things I'm missing here. When I look at all the things we have to do, and how much talent we have to do it, I just can't fathom things going well. At least I know I will do the absolute best I can :)

No comments: