Comments on: Systems Development Question

By: extradrunk

extradrunk — Tue, 07 Feb 2006 00:35:31 +0000

your CIO has an idea of what he wants out of the system that is why he implemented a model like that…. not only does it give you an idea of what your supervisor want it also saves time and human effort. rather than starting to get opinions and formulating a sample design then having it evaluated again . just think of it as a rapid application design(RAD)*

By: jburelle

jburelle — Thu, 02 Feb 2006 10:12:22 +0000

BeerMaker had some very strong points. I would add to that you document everything, save all emails, and make sure you ‘know’ your CIO. In a perfect work environment the CIO would be intelligent and have an ego that would accept suggestions, that said, we know that is not always the case. Good luck.

By: beermaker

beermaker — Thu, 02 Feb 2006 09:54:23 +0000

A good CIO would never make final design decisions without getting a signoff from the key players (its eventual suicide that will get noticed by other executives).

However, since he is very confident he knows more than they do, lets assume he is right. The users may want to do things the way they always have, but the CIO may be trying to automate a manual process or eliminate unnecessecary steps. It takes a good business analyst to look at the whole process and eliminate unnecessasary steps while improving the application.

Your goal should be something like this: be a hero to the CIO and the users. Make the CIO look good. If the CIO’s actions are preventing you from this mission you will have to do it without appearing to be insubordinate. Communicate with the key players or other users directly and informally. Find out what other commercial packages are doing. Figure out if the CIOs decisions are correct and dont be afraid to keep him from making a big mistake. Express your concerns that he would look very bad by going down the wrong path (if you find this is the case) and that a little “time wasted” talking with the users will help avoid a disaster. Go the extra mile and the CIO, users, and other Executives will take notice.

Recommend to the CIO that he get a “signoff” from the users to cover his ass. If he does not go for this then your suspicions are confirmed and hes putting his job at risk. Lets hope you dont have to be a casulty of a failed project.

Best of Luck

By: kingtut

kingtut — Thu, 02 Feb 2006 09:33:04 +0000

People are better editors than authors. No matter what you call your process, giving the users a strawman to elicit responses is usually much more efficient than giving them a blank page. The former, even if it is not a great starting point, will get you to the finish line much faster than the latter approach. During this fleshing out activity, it is important to capture and evaluate the current business processes, too. Creating or upgrading a business system without simultaneously improving business processes cannot lead to any significant improvement in business efficiency. The design phase must also include an evaluation of the commercial products available. A business justification for make versus buy is the only way to be assured the chosen path is the correct one. Today, modifying business processes to fit a commercial product many times result in the best result to the bottom line.

By: bobkberg

bobkberg — Thu, 02 Feb 2006 00:26:09 +0000

Depending on your level of guts and/or comfort, you might ask your boss if he is willing to take personal responsibility for project failure.

Alternatively (and much safer), set up a series of meetings with the various folks who take care of each set of steps through the process, and without tipping your or your boss’s hand, ask each of them to describe the process as each of them sees it, and take lots of notes. Hopefully you can get your boss to sit in and listen on the pretext of finding out if there is anything going on under the covers that has never been brought to light.

That was one of my early experiences in software design – and it served as both a disaster and an eye opener.

Who knows? He may learn something!

Bob

By: dyafrica

dyafrica — Thu, 02 Feb 2006 00:22:45 +0000

Thank you very much to all of you!

By: venphil

venphil — Thu, 02 Feb 2006 00:02:16 +0000

I’m afraid what this really boils down to is “who is signing your paycheck?” The first thing to do is talk enough with the CIO to see whether he or she seems to know what they are talking about, and then decide whether you wish to continue or bail out (which, if you work for the company probably means resigning).

Then I would suggest building a prototype that works according to his specifications, and try it with users, and let the CIO know what works and what doesn’t work. The CIO may in fact be trying to tell his division how work should be done there (this is his job, actually).

The you can proceed with the implementation of the (possibly redesigned) project.

REMEMBER: if you decide to continue on the job, your main job is to implement the CIO’s “vision,” and you must do this without any reservations or hesitations or ill-will. I DO NOT RECOMMEND doing something you DON’T want to do, both for your sake and the sake of the company.

All of the earlier comments are valid, and in the end irrelevant if the CIO is calling the shots. It’s an “interesting” situation. Check out the competence of the CIO, and whether he is open to reason (meaning wanting to understand whether his idea will really work. It is, of course, against his own best interests if the system fails for whatever reason, which in the case you describe will be of his own design.

Good luck, and let us know what happens.

Ven. Phil

By: paul144hart

paul144hart — Wed, 01 Feb 2006 16:56:52 +0000

I’d start looking for another job. If the CIO is designing the system, he isn’t being the CIO. I predict the next phase after introduction will be the hunt for the guilty and punishment of the innocent.

By: drhowington

drhowington — Wed, 01 Feb 2006 14:03:13 +0000

There are too many variables here to answer whether you are right or your CIO is right. However, the CIO is in his position because someone or a group of someones values his opinion and his methodologies. He is the boss. Your job is not to correct him but to support him. You must make his approach work with the minimal amount of cost to the company. Make sure the users’ input that the CIO has invited is comprehensive, be sure they understand the processes and how they fit into their work. Make sure they agree and and don’t see a better alternative. Otherwise, make sure that they provide input for changes to the design up front, as soon as possible.
Traditionally, the IT department must remember that it is a cost center that provides services to the user community and the company pays the overhead cost for IT in order to assist the users in doing their job as they need to be doing it. Typically the designed system must change to suit how business is done and not the other way around. Therefore, the ideas and approaches typically must come from the user community or at least the user community must furnish input that drives the design; not the other way around.
But, remember you have only three alternatives; 1)make your bosses into heros, or 2)know that you are limiting your career progression, or 3)go work for someone else.

Good Luck,
Dr. Mike

By: rshyleshnair

rshyleshnair — Wed, 01 Feb 2006 13:46:34 +0000

I find it interesting that a “CIO” has time to do systems design and analysis and data mapping and writing up technical and functionals specs for the development team. What happened to the the systems analyst. From a cost perspective, I see his point if it is safe to assume that he is the business/functional expert on every functional role in the loop, however if he isn’t he will end up running cost variances in wasted effort (his salary/# of hours taken) + any other resources he has taken to revisit, redesign, re-map processes. Most of the time if you approach the end-users and ask for a “wish-list” you are not guaranteed that you will get a best-practices schema either. Its always nice to have “must-have” vs. “nice-to-have” so that users feel that their input is being considered and ultimately your CIO gets to make the call on what should go in or out. If you are driving a process re-engineering change through this new in-house system, an industry expert could be consulted to give you input on what best-practices are.
Also if the code being developed has to be re-written, re-tested multiple times (I assume that you will take the phased approach towards implementation)and any major rules have to be rewritten you might as well take your developer’s/consultant’s rate/hour *# of hours spent re-writing code to fit test specifications as well. There is nothing like having a spreadsheet or report that shows cost overruns and ROI- it speaks volumes silently. Tact in expressing your waterfall alternative is always well served for your own future career. Good luck!