Systems Development Question

pts.
Tags:
Development
Lifecycle development
Project management
Dear Colleagues: My company currently develops an in-house loan system for its own use. I am used to the "waterfall approach" where users' inputs are gathered prior to system design and development. In our company's case, however, the CIO makes his own system design and asked the users for comments. Is this be an acceptable practice? According to our CIO, he used the "best industry practices" as benchmark. He argued further that asking for users' inputs prior to system design could take more time than making the design himself and asking for comments after. Although after making his preliminary design, numerous comments were received from various user departments and a redesign is necessary to custom-fit the system. Which is a more practical option? Is my CIO's practice more applicable or the Waterfall/traditional approach? Please advise. Thanks.

Answer Wiki

Thanks. We'll let you know when a new response is added.

Hey Dyafrica:

Designing any kind of application or system requires input from the users. Especially if they have an existing system to compare it to. Unless the CIO is deeply familiar with every aspect of every job within your organization, he would be better off asking the users by department, or whetever, to make input, and design the system for one department at a time.

IMHO, the best practice, is to ask the end users what they need, then design based around that.

See Ya!
~Brant

Discuss This Question: 22  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • SheldonLinker
    It has been said that an elephant is a mouse designed by a committee. If you have no idea what it is you should be making, then (a) you should ask the users, and (b) how did you get to be CIO in the first place? When you do ask them, you will get as many different ansswers as you have users, all going different directions. You will then have to sit down and assemble a cojent plan from the answes. If you _do_ have a pretty good idea of where things need to go, by all means, put that out as a plan, and ask for comments on it. In doing so, you will focus the users on a general direction. However, make sure that you have input from the high-producers as well as the malcontents. Both fringe groups will tell you things you really need to hear. Last, keep in mind that you're unlikely to please everyone. If you try to please everyone, you're likely to go way over budget. Feel free to spend $10,000 to save 100 users $1,000 each. Be careful not to spend $10,000 to save 100 users $10 each, or 1 user $5,000. I'd say you're on a good track, but not the only good track. --- Sheldon Linker (sol@linker.com) Linker Systems, Inc. (www.linkersystems.com) 800-315-1174 (+1-949-552-1904)
    30 pointsBadges:
    report
  • Japeters
    There's really no right or wrong answer until the outcome plays out. If it requires a total redesign after the users get ahold of it, and that ends up taking twice the time it would have to do it the other way, then he's wrong. If the changes are easily addressed and are more efficiently proposed because he went ahead and built it, then he comes out of it smelling great. Best practice isn't always as best as it sounds. Your CIO may very well be right about the time wasted consulting the users upfront. A lot of the users may not have the insight into how their business processes fit into the greater operation, and may not have the right questions to ask up front. The best input a user can provide is to tell you what's wrong with the current system as it relates to their function. If this is a new system, you won't get that kinda feed back until there's a sample in place for them to pound away at. Spending too much time asking users up front to try to conceive of everything that they will need or want while staring at conceptual flow charts is just going to be a waste in many cases, and maybe that's what your CIO is recognizing based on his experience. It should be obvious that SOME level of user survey should be done upfront, unless the CIO is extemely in touch with the processes and can whip up a demo with out much effort. But there's always going to be a fine line between spending time and wasting time when it comes to planning any project. If i sit here and talk about starting a new business for a year and a half to make sure i cover all the aspects of the operation in theory before proceeding with formation of such, someone else will beat me to market with my concept. that's my take.
    0 pointsBadges:
    report
  • JoseRaniero
    I used to work in a small company where the application requirements were dictated by the CIO and after exposed to the users. Unless the CIO is very aware of the user needs this approach is not optimal. One of the main reasons for a project failure is bad understanding of the user requirements. In order to have a good understanding of the user requirements the waterfall approach has to be avoided. A good understanding of the user needs can be obtained with iterative approach as UP. The CIO can give a
    0 pointsBadges:
    report
  • JoseRaniero
    I used to work in a small company where the application requirements were dictated by the CIO and after exposed to the users. Unless the CIO is very aware of the user needs this approach is not optimal. One of the main reasons for a project failure is bad understanding of the user requirements. In order to have a good understanding of the user requirements the waterfall approach has to be avoided. A good understanding of the user needs can be obtained with iterative approach as UP. The CIO can give a first draft of the requirements, but these have to be validated by the application final users
    0 pointsBadges:
    report
  • Huguessauzier
    As opposed to the Waterfall Approach, there is a better approach called evolutionary prototyping which involves key users of the system more deeply into the system analysis and design phase. You can find a wealth of information on the Internet about Joint Application Design (JAD) which underpins the evolutionary prototyping approach. In any case, whatever methodology you use, the business experts and the key users are the ones who need to provide information about the required functionality of the application being developed. The CIO cannot substitute himself for the business expert.
    0 pointsBadges:
    report
  • JBurelle
    I have to jump in here with a true story. I once worked as a consultant at a big supermarket chain in our area. The Vice President of Information Systems had me create a warehousing system from his specifications. At each point I kept asking him if he had shown it to the users, his reply was always that HE knew what they needed and HE wanted to make sure they did it the right way (his way). After six months of hard work we put the system live. The first response of the users was 'We can't use this!!!'. I spent the next week working round the clock to modify the system so it worked with their environment, their equipment, and their work flow. Be wary, very wary of anyone who says they know exactly what the user needs without getting any users involved.
    0 pointsBadges:
    report
  • TennPgmr
    Your CIO is effectively telling the end users he doesn't value their input. Accepting input after he has determined his best design results in the bar being higher to sway the design - afterall it is already on paper. Your CIO would also manage the environment of change better by encouraging everyone to be a part of the process. Good Luck!
    0 pointsBadges:
    report
  • Hrwoytash
    There are 2 issues here as I see it. 1) You probably report to the CIO - if you do then you really want to "work with him" or your future is bleak. 2) The users really need a solution that will meet their needs. A possible tactful resolution : If the project is complex enough, try to develop it (an have the users test it) in phases. This can allow you to get their requiremnts and changes in without having to choose to go head to head with your CIO. You could develop phases either by starting with basic vanilla system end-to-end with addl phases adding functionality, or by stepping through the process in Logical work functions.
    0 pointsBadges:
    report
  • Stanton
    I think it might be best to ask your CIO why he chose to do it that way versus the waterfall approach. He may have a reasonable explanation. After he has explained his approach, then you get to decide if it is reasonable and if you still want to work for this guy.
    0 pointsBadges:
    report
  • DaveInAZ
    I think it all boils down to "Was he right?" and "When did he ask for user input". If his design absolutely nailed it, covering all the users wants and needs as well as integrating perfectly with whatever other systems it needs to and meeting all the business's needs, the discussion is over. He's either a supergenius or a wizard and you should thank your lucky stars that you can learn from him. But, there's another development model that he may be using, or at least basing his style upon; the Agile methodology. In Agile, the designer learns the basic outline of the functionality needed (with minimal, if any, user input) and builds a working prototype. That is presented to the users for comment, and the comments are used to build the next version, which is presented to the users for comments... etc, etc, until a "final" product is achieved. The trick is in knowing when you're "done". (No software project is ever REALLY done until it is obsolesced.) I would hope your CIO has enough of an understanding of the company's processes to be able to an initial prototype of this kind without user input. If that's not what he's doing, I hope you work for Wile E. Coyote, SuperGenius.
    0 pointsBadges:
    report
  • carlosdl
    I agree with Stanton. May be you need to ask your CIO why he chose to do it that way. Sometimes the end users don't know exactly what they need, mainly when talking about a new system, in that cases the prototyping approach mentioned by huguesssauzier is very useful; you work in phases and get feed back. Prototyping gives you a way to know user requirements. May be your CIO has a good understanding of the process, and he knows that asking end users what they need could produce a hundred of different answers. May be your CIO is right, may be not. It depends on the situation, which you surely know better than us. Good luck.
    69,920 pointsBadges:
    report
  • Cathysnarey
    Hi, I would say you will probably end up with problems with either approach in the situation you describe. Perhaps a 'politically correct' approach incorporating your CIOs design as a first input to a small number of RAD style requirements/design workshops with a select group of representative end users, with the end objective being a design agreed by both the CIO and the end users? You would need to ensure that the workshops were held in a very short space of time and that you sent out invitations containing very clear objectives and a copy of the 'first cut' design to enable them to prepare beforehand. - and a bowl of jelly babies always helps keep the participants blood sugar up............! best of luck, Cathy
    0 pointsBadges:
    report
  • Rshyleshnair
    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!
    0 pointsBadges:
    report
  • DrHowington
    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
    0 pointsBadges:
    report
  • Paul144hart
    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.
    0 pointsBadges:
    report
  • VenPhil
    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
    0 pointsBadges:
    report
  • Dyafrica
    Thank you very much to all of you!
    0 pointsBadges:
    report
  • Bobkberg
    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
    1,070 pointsBadges:
    report
  • KingTut
    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.
    0 pointsBadges:
    report
  • BeerMaker
    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
    0 pointsBadges:
    report
  • JBurelle
    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.
    0 pointsBadges:
    report
  • Extradrunk
    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)*
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following