Client Interets
The "Client" was actually represented by 4
parties.
- An IT Manager, who is in overall control of the budget,
but doesn't actually have any involvement in the hardware or software.
- The Systems Manager, who looks after the operating of the
Client's hardware and software.
- The Sales Team, for whom this product is being built.
- The boss, who pays the bills, but doesn't appear to
understand what all the money is being spent on.
It is important to appreciate the characters and dynamics
involved. I won't go into too much detail to protect their identities. The IT Manager is
extremely demanding. The IT and Systems Managers are best of buddies. There appears to be
a power struggle between the IT Manager and the Boss. As will become apparent, we don't
know about the Sales team. By the time I am involved, the IT Manager has already fired 2
project managers, supposedly on technical grounds, but realistically more because the two
sides didn't get on.
Part of project management involves soliciting
information from the Client - what do you want? How are you going to use it? So far, are
we on the right track? As I said this system was to help the Sales Team and to a degree,
the Accounts Department. The IT Manager explicitly refused to let us talk to anyone else
in the Client's company except himself or the Systems Manager. He is the one approving our
pay, so what he says goes. He feels that he alone is capable of determining the result of
the project and therefore can manage all aspects on behalf of the Client. Unfortunately,
project management is all about collaboration.
The Systems Manager, before any coding has started or
even the system processes are worked out, decides to spend $300,000 on hardware and some
specialized software for this new system. It may be the best, fastest, biggest, most
powerful, most prestigious, newest on the market, but at this stage we had no idea whether
we really needed something that powerful. As Project Manager, you determine the technical
specifications of the project and advise the Client. But at the end of the day, it's the
Client's money!
Not surprisingly, with the size of project and the many
skill sets required, there were several different people involved on the "Supplier's
side". We were in charge of the project management and a substantial amount of the
coding. We had 4 people full time working on the project management team. One of our
number could probably have been described as fulltime Liaison/Buffer to the Client, while
the rest of us got on with the job.
In addition there were yet 4 other parties working under
the direction of our project management team.
Party "1" was involved in designing the
database.
Party "2" was involved in building that
database and doing the required coding.
Party "3" had to provide communications between
the several applications we were building.
Party "4" had to look after security measures,
review code and do final testing (and keep an eye on us).
The project was is to be built in phases. Party
"4" has just lost the contract to look after the project. It is therefore in
their best interests to see us fail. As I mentioned they are to review our work. They have
tasks to do for the project and naturally it's the responsibility of the project
management team to ensure it happens properly and on time. So due to the obvious conflict
of interest, requiring them to do their part in the project, is always an issue to be
handled with care.
Another case of kid gloves: We need the $300,000 worth of
hardware and software to be configured in order to set up the environments for our work.
Without it, we are spinning wheels, "it's a Milestone on the Critical Path". It
transpires that the Systems Manager is in over his head. As a result we have to delay the
project. Given that the last Project Manager was fired when she voiced her view that
several delays were due to the Systems Manager, we accept responsibility. Unfortunately
though, we are not able to address the root cause.
However the environment has all been set up by the
Client, since they chose the development teams and had already purchased the hardware and
a substantial amount of "Off the Shelf" software. As a Project Manager you
cannot really tell what the issues will be until you get into it. Sure, we knew what was
needed to do to make the product, but we also needed information from the Client and
support from the whole development team. Add to the mix, the fact that we are all working
out of the Client's offices and that half the team speak English and half French as their
first language, communication takes on an even greater significance.
We end up expending significant energy (and hence Client
money) on trying to extract this information and keeping the Client happy that work was
progressing. All the while knowing that the real end users are yet to have any input into
the product.
When we finally finish the product (really just a phase
of development) and give a demonstration, we are finally allowed to present it to the
Sales Team. They duly watch the demonstration "Looks nice, getting there, but doesn't
exactly do what we need, we have a few questions . . ." Interesting feedback to
receive after supposed completion.
Academic vs Business Writing
By Jane Watson
On the morning of a second day of a business writing workshop, one of my participants
said, "My wife is an English teacher. When I told her about the changes in writing
that you taught us yesterday, she got very upset." [Read More]
Your Thoughts?
What are your thoughts on this? Drop me a line at ivan at klariti dot com |
