Need your advice on consulting!

Hi!

I ahve worked for a big swedish company as webmaster, .net programmer, architect for about 6 years. recently I quit and started to work for an IT consulting company much closer to my home town. And the first project I was assigned worked very well, since then I was responsible for the design and development.

Now for the past 6 weeks I have been working for another customer in another project. And well, lets just say that Im at home right now on sickleave because I had some kind of mental collapse last wednesday evening (after a 14 hour work day). Im feeling okay now and I hope I can get back to work in a few days. But I have had some time to think about what went wrong and how I could have prevented this mess.

For starters, the project had a timeline of 6 weeks. My responsibility was to create a database for some data, write some stored procedures that processed this data based on some business rules and to export a csv file that would be imported into their ERP system. To begin with, I have no experience whatsoever in financial systems, and this reconstruction of the data was pretty complicated. The input data was given to me as pivot diagrams, bits of text in emails etc etc. No analysis had been done on the data to verify that it could be processed with their business rules. And the business rules was written on such a high level that it would be impossible to write code just by reading them. At least impossible for someone that didn't have any experience in this field (my background is technical, not financial).

I started by designing a database to hold the data. There was no method to verify the integrity of the data, and I could use no other PKs other than an auto number for all the tables, because there where multiple identical records and they couldn't tell if it should be like that or not.

Then I started to design the stored procedures. And immediately I hit several big problems. I should distribute money (from a table) onto the assets (the other tables) based on a distribution matrix. The problem was that these three items didn't match. The money was structured some way, the assets in another way, and the distribution matrix in a third way. This means we had to start writing translation tables so I could write the logic. Pretty soon the database diagram become very complex, and the design got worse for each passing day. When we finally had some runnable scripts that did work, I sat down with the "expert", since I had no written specifications, I had to sit down with him and we went through line by line in the specification and he said, yes that should do it! Ok, now I thought we had QA on the scripts, so we started to run the scripts. When they later analyzed the result it was a real mess. Nothing was ok. I had created a dummy record to hold the money that could not be inserted, and this had a pretty big amount. This meant that the business rules where flawed, because the logic could not distribute 100 % of the money onto 100 % of the assets. Now I felt that the persons responsible for the solution started to get desperate, because they started to go on in terms of "try this.." "change this...", "what if we do this..."

Now we where about 2 weeks from the put in production date. It went on like this for about 1 week, lots of overtime. And then they found out out of teh blue that they could not calculate deprications for the assets in excel, as their plan was because the calculations where too complicated. They wanted to do that in the database instead. Ok, one week to deploy date, scripts where still beeing tested. And they had no clue what so ever on how we should do this. We had about 14 different scripts, and the deprications should be distributed pretty much in the same way as these scripts. They thought we could just copy paste the original scripts, and do changes whenever it was needed. At this point I was about ready to just go home.

It was later that same evening when they tested one of the scripts and found out it didnt work... then I had some kind of beakdown in teh restroom, and I had to ask my dad to come and pick me up because I couldn't drive by myself.

And now when looking back at this, I asked myself 100 times, what could I have done as a consultant to prevent this. I came up with several things I would do if I was the project manager

1) Spend more time on analyzing the data, to find out the quality and if it works with the business rules. This can easily be done in excel and access.

2) Spend more time on the business rules, write them in more detail so someone that isn't skilled in financial terms can understand them.

3) Write some kind of test specifications, e.g. how can we verify that the scripts perform the way we want. As it was most of the time, they had no way of knowing if my scripts performed 100 % as they should because it was written as trial and error and assumptions.

My task was to write t-sql scripts and to create a database. I must assume that my job was not in this case to write some kind of system specification (which was really needed). I could have told them right from the beginning that its impossible for me to write scripts if you had not figured out how things should work for starters. But this was my first assignment at this company, and by the time I realized where this was headed, it was too late.


what do you think? How should a consultant act in this case? Because such assignments are futile both for the health of the team members and for the project itself and its deadline. At my previous work we found this out 2 years ago, and made damned sure that projects like this where never allowed to start.

kind regards
Henrik

Well I have been through a project like this back in 2001. What the issue was similar that they didnt like the data results of their fiancial records totals. They had me go over it again and again with new formulas based upon how "they wanted" to calculate it so it gave them numbers they wanted. Didnt matter if they were wrong, just to be able to prove the calculations would be correct in case of an audit.

What I learned from this was that the project manager didnt have any stipulations in the project guidelines and tasks when they signed on that allowed for us to get out of the project of doom.

Since then I do all phases of projects now and I have clauses when clients sign on to a project like this that they are responsible for providing the formulas before any work is to be done and that any changes in calculations wil require a quote adjustment (more $) which helps to relieve the streess lol.

See, CFO's only look at the bottom line and if they like the numbers then they like the project. So much for everyone else that is involved in the project.

Basically, a caluse stating that they

Will provide accurate and valid data
Will provide the formulas or methods for calculating the data
Any deviations from the project quote will require additional funds or a requoting of the project to include the new changes.
Any changes in the project's quote will also require changing the project timeline/due date.

This turns it back on to the clients responsibility. If they change the requirements then they know they are changing the timeline and due date. So no worries. Its just a T/M project and you get paid per hour so its all good :D

hi,

sorry to hear of your breakdown, Hope you feel better soon, i know what it's like to deal with a condition like this. i have problems when i am relying upon another dept to progress work and they drag their heels. i get frustrated and adjetated and have also had breakdowns.

it would apear that the source of the problem above is that the specification was not correct or detailed enough at the start. i have experianced this many times and although i try to build rules to prevent it, i can still experiance the same issue. as you don't fully understand your enviroment this too is going to add to the issue. i would try and understand the enviroment and quote acordingly to accomodate this.

thanks

David

The bottom line is:

Don't write a single line of code (or even think about writing code) until the entire project is specified out, to the last detail, in writing. Then write the code to produce the result in the spec. If they don't like the result, they wrote the spec, so they can only complain to themselves - you wrote code that produced the result they asked for.

I refuse to accept any client who doesn't know exactly what he wants, or won't agree to sit with me and decide exactly what he wants, before I do any design work. Life's too short.

I agree with most of what everyone else is saying but I think it's a slightly simplistic view.

In the real world it's common for clients not to know exactly what they want and, if you want to call yourself a consultant rather than a programmer, it's part of your job to help them past that barrier. Ideally you'd want to get their system fully analysed and specced before writing a line of code but it's likely that you won't have that luxury because there's always Bodgitt and Legitt Development Co. just down the road who'll be happy to start off on half a spec and bump the quote later once they've got the customer financially committed. You want to get the best and most detailed spec you possibly can up front but if you think there'll be no toing and froing after development begins you're fooling yourself.

I personally think the most important thing you can do is temper the customer's expectations by stating that quotes, timelines etc are dependent on certain assumptions and are therefore subject to change (RD's clauses express it much better than I am here).

Further, develop a good and freindly relationship with the client - give them a free change or two if it makes them happy... but charge extra for anything that looks like it's going to take more than an hour or so (factor this free stuff into your quotes so your not left out of pocket). You don't have to win every argumnent with them and you don't need to give them everything they want either - you just need to appear reasonable and professional. Make freinds with their techy guys too - these people can be your greatest ally or your greatest enemy depending on how you treat them. To me, inter-personal skills are every bit as important in this industry as technical skills.

And the most important piece of advice is not to take it personally. You're doing a job and it ends it 5:30. Go home, have a glass of plonk and put your feet up. Obviously we all go to bat for the company and work long hours when the preverbial really hits the fan but you need to let your boss know that your picking up someone else's pieces. Your doing the company a favour at this point and you'll find it's much less stressful if the company's grateful.