[Sigia-l] love thy client

[Pittas Marios]

> I put this question. What about when you make a prototype in one or two
> months (medium complexity project) and when it is done the clients says,
> we don't want to proceed with the project. But then after a week or two
> one finds out the prototype is being used to process real work?

That's why it is often suggested that prototypes are not created using
actual "development" systems because:

1. The prototype is meant to be a quick and easy way to show what the system
would look like/behave like and thus changes should cost minimally (which is
not always true with "proper" development environments where changes can be
very costly). Therefore, there should be very little problem/discussion
regarding the effort to change the prototype.

2. When one works with prototypes produced by development systems, one has
to focus either on the "quality of code" vs the "flexibility of the
prototype in meeting the customers requirements". Quality of code is often
desired because developers want to use the prototypes to evolve it into the
actual systems. But if you continually keep changing the code to evolve the
prototype (as per 1) that code will be buggy, messy, unmaintanable, etc..
(engineering will scream at you..) Flexibility of prototyping should be
desired because the prototypes most important reason for existing is to
provide the development team/clients with a type of pre-visualisation of
what the system would look like, thus flexibility

For this reason, if you are working with a team such as Lotus Notes/Domino,
etc. "force" (ho ho ho...) such a team to use paper/html/anything but the
actual development environment to create prototypes. Introducing processes
with deliverables (such as "Prototyping Stage: Paper Prototype of the system
with buttons and links to other pages but not.... etc"..) is highly
suggested.

Marios

-----Original Message-----
From: sigia-l-admin at asis.org [mailto:sigia-l-admin at asis.org]On Behalf Of
Nuno Lopes
Sent: 03 March 2003 09:56
To: sigia-l at asis.org
Subject: RE: [Sigia-l] love thy client


Some of the problems between client and supplier within this Industry
are due to lack of leadership, sponsorship and finally communication.

Too often a project starts with the lack of a strong sponsor, with real
decision making authority. The steering committee is sometimes ill
composed in terms of expertise and decision power. Put into the mix
enterprise politics and we have a good start for a dangerous cocktail.

As told by Christina the responsibility of a consultant is to listen,
understand and act according to the project objectives. But the
responsibility of the client is still to communicate what he wants.

Prototyping should be a rule for medium to complex project but too often
the client does not even want to even hear about that. Whether the
budget is too short or simply the convincing sale pitch raised the bar
of expectations so high that just the word "Prototype" coming from the
consultant mouth might be taken as lack of consulting experience within
the problem scope by the client.

Beth wrote:

>Does it come as any surprise that this can be really hard for the
client
>to do as well?

Finally some sense from a client that seam compatible with me. No it
does not but then that should be accounted in the project schedule where
the client is not just a passive stake holder in terms of responsibility
around a project deadline but understand that its an active one.

But again this idea is quite often missed by clients. When I see
proposal with beautiful Gantt graphs (project schedule) and a long story
line where not even the information model is defined a bitter taste
comes to my mouth. Bitter even when a proposal is refused because after
the client expected one after one or two meetings.

>I'm working with our IT department on an application, and we know we
have >to log interactions, but the "last big thing" we had to figure out
>(according to IT) was what the heck the  system was supposed to do with
log >file data that was more than five years old.

I understand this because I've been face to face with it. What I can say
about this is "take ownership". If decision is your responsibility and
you're not prepared to decide say so to the IT department. Mention that
fact to the project manager (if one is there) and renegotiate project
priorities.

>When it doubt, punt. We need
>to get this working and figure that out later. Yes Virginia, it is a
>risk. This one we'll have to live with.

Excellent. But the next question is how much later? Because the approved
budget is X, and this means Y days of work for a consultant. This is of
course extreme but when things go wrong there is no goodwill.

I put this question. What about when you make a prototype in one or two
months (medium complexity project) and when it is done the clients says,
we don't want to proceed with the project. But then after a week or two
one finds out the prototype is being used to process real work?

I repeat what I've written before:

All in all software development is a complex activity that with the
Internet as been neglected as simple or trivial.

Too often I've heard don't worry about technology tell me what you want.
Also too often I've the reason why the project failed is because of the
technology (bad product, really bad product). I believe both kinds of
statements are used to cover the real truth about what went wrong most
of the times (or actually it might even be the fact that went right
after all for someone else).

I believe there is a deficit of business ethics in the software
industry, and particularly in the newer software markets like CM, from
clients to vendors and vice versa.

Although I fully agree that IT is more responsible for the state of the
art then clients are. So the solution for the problem can only start by
consultants and vendors do what they say they do and are supposed to do,
nothing less nothing more.

Best regards,

Nuno Lopes.


------------
When replying, please *trim your post* as much as possible.
*Plain text, please; NO Attachments

ASIST IA 03 Summit: Making Connections
http://www.asist-events.org/IASummit2003/

Searchable list archive:   http://www.info-arch.org/lists/sigia-l/
________________________________________
Sigia-l mailing list -- post to: Sigia-l at asis.org
Changes to subscription: http://mail.asis.org/mailman/listinfo/sigia-l
---
[This E-mail was scanned for viruses.]



---
[This E-mail was scanned for viruses.]