Developing in Thin Air: How to Effectively Drown Your Software Schedules
-- Jonathan Ng
Still hanging in there? ;) Well, this month, I'd like to talk a bit about being cheap.
It is an unfortunate thing, but more often than not, businesses are resorting to drastic
measures in order to turn a (better) profit at the end of the quarter. Many are also
buying into the leaner and meaner "stereo-Hype". Admittedly, the world is highly
competitive. A leaner organization certainly has its benefits. However, often the means by
which a better bottom line is achieved are less than desirable and in certain cases can be
counter-productive.
On a recent consulting assignment, my team and I were asked to provide a solution in
response to an RFP (Request for proposal). For those of you not familiar with consulting
practices, generally what happens when a potential client wishes to have a custom product
or "solution" is that they put out an official Request for Proposal which
different consulting companies can each respond to and bid upon. The client then gets to
pick the solution that fits their needs the best.
In this particular assignment, the RFP requested a solution, which would provide
distributed client functionality where clients would dump data into a master repository to
be kept at a given location. Some of the data entry people would have existing systems and
a conversion tool that would convert their entries into a master format, while others
(still on a paper system), would be given a new client. In both cases, entries were to be
transmitted over a network to a central database. Security was obviously essential. (Due
to confidentiality reasons, I am unable to disclose the nature of the system.)
There were four people resourced to the assignment -- one project manager, one
technical architect, and two analysts/consultants. All of us were relatively new to the
company, with the exception of the technical architect. As you might expect, there was a
degree of inexperience in the group. Since we did not have the resources of any of our
senior architects at the time (because they were all busy working on their own projects),
we were forced to write the proposal without having any reasonably experienced person with
whom to consult. Nevertheless, we prevailed with a viable solution -- one that was even
better than the proposed suggested solution in the RFP.
We came up with a solution where the existing systems would continue to enter their
data into their respective products. Conversion utilities and bridges would be written to
replicate this data to the master database. Paper systems however would be converted over
to a thin client solution, which would employ a web browser on the client end and a secure
web server running on the master database end.
Our rationale for the decision was threefold. First, this solution offered tight
security -- 128 bit RSA encryption. It would be provided at a fraction of the cost (since
clients were already pre-existing). Finally, it would be very easy to maintain since any
changes would only have to be made on the server.
We spent about a week writing the proposal according to the requirements that were
given to us from the potential client. This included an executive summary, a proposed time
line (created using seat-of-the-pants estimates by our technical architect -- but that's
another story), our proposed solution, and then another fifty or so pages that outlined
the normal "we're the best" company propaganda (*sigh*). All is well -- so we
thought.
Day before Deadline
We finally got hold of a senior architect to look over our proposal. He immediately
told us that there were issues with the proposal, and that it would have to be redesigned.
Fair enough, but why didn't he tell us earlier? It's not very tactful for someone to
ignore you for a week complaining of a busy schedule and then just muddle in to dismiss
all the work that had been done in his absence!
It turns out that the architect thought our solution was too risky. The client had in
mind a Microsoft Access client for the people who were on the paper system. The data would
then be replicated to the master repository at given intervals. If you think about it,
this solution really wouldn't meet any of their requirements - First, security is nearly
non-existent in Access. Second, maintenance is hard and clumsy on fat clients; finally
costs are high because Access isn't free, nor are database developers.
In a way, the architect was right. Clients who are this set in their ways usually
aren't open-minded and will look for solutions that they perceive to be cheapest. What we
had proposed might have worked with another client, but given the situation, it just
wasn't appropriate. Furthermore, the architect had a fear of the unknown, and was weary of
web solutions. He thought it to be a risk that in the event the contract was awarded, we
would actually have to implement such a solution!
The next morning, he told us forget the whole project altogether. Well, as you can
imagine, we weren't very happy about this decision. The four of us just spent an entire
week coming up with a proposal, which got scrapped by a single person! We saw our entire
week's work flash before our very eyes.
Conclusion
This is an interesting case, and there are several extremely valuable lessons to be
learned from it on all sides of the equation. No one particular group is completely at
fault, and thus I have split the lessons into the three parties.
Managers and Senior Technical Architects Know where you're headed and what you've got
before going there! In competitive times like this, you're being foolish if you think that
allocating four people on a project for a week just to throw it out is an economical
investment. Of course, you'd never think to do that from the start, but by hoarding people
with experiences that are necessary for such assignments, you run the risk of having your
cheapness backfire on you.
Clients What you think is the best and cheapest solution may not be -- especially if
you're not in the field. The fact that you are putting out a request for proposal means
that you trust an external company to provide you with the best solution for your needs.
Meeting client needs is one thing, blindly following their requirements is another.
Consulting teams If you know your own senior people are going to scrap your project,
you might as well play cards. :) In other words, know your abilities, your client and your
manager. On a more practical note, always ensure that you get signoff from the appropriate
people. This includes people who have knowledge and expertise in that area. You may not
like their decisions, but it will save you grief.
Comments
I always welcome your comments, criticisms and suggestions for new topics. Please feel
free to email me at ngt@canada.com.
Last month, I asked for some suggestions for a name. I received several, but I can't
decide! I'd like the name to reflect the nature of the column. It is primarily a column
that provides editorial commentary of software engineering and its practices in industry.
Though the past couple of articles were on various downfalls of the corporate world, I am
hoping that the column will not be limited to such stories. I intend to also write about
successes. :) I believe in both the theoretical and applied aspects of knowledge and
always try to bring balance to my work.
Below I've listed some of the suggestions I've received (with appropriate credit). I
liked all your suggestions (though I did find some of them too long). If you have any
more, please send them my way!
"The Real World: Guidance for Managers and Other Dreamers" (Alan Falloon - U
of Sask)
"The Corporate World and its Downfalls" (Brent Towsley)
"The Null Pointer" (Ranyl Bantog)
Acknowledgements
Many thanks to Karen Lo and to Jeff Daviss who helped on countless occasions to edit
this article and others.
|
