Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

When Programming Leads to Policy Making 1

Status
Not open for further replies.

Mike555

Technical User
Feb 21, 2003
1,200
US
Over the past few months I've been developing a large MRP application for my employer. Although at times it seems overwhelming, I love building the application and this is the first true 'enterprise-wide' application I've developed entirely by myself. The application (when completed, hopefully) will truly streamline many processes and make it possible to track and store information our current system simply cannot process.

There is one aspect of the entire process that perplexes me. Whenever I meet with management to discuss the new application, management frequently asks me for my suggestions on how THEY should handle the new data. Instead of simply telling me what they want, they often ask me for my suggestions. For example, they may say "Now that we can track the manpower cost of 'x', how do you think that should factor the profit of 'y'?" Or "That's great the new system will allow us to monitor the progress of vendor requests, but which department do you think is best suited to monitor and track this information?"

I don't mind giving suggestions whenever they ask me questions, and infact I think it may increase my chances of getting promoted in the future. But I wanted to ask, is this type of thing normal? In your experience have you ever played a central role in developing policy as a result of developing an application?

--
Mike

"Don’t get suckered in by the comments – they can be terribly misleading. Debug
only code. – Dave Storer.
 
Been there, still there.

Every time that there is something "new" that I add to one of my apps, I endup giving out the responsibility for it. Started the same as you, now it is to the point that I tell them how it is going to work and flow (being poitically correct and not stepping on toes). At this point, most of the managers expect it of me and unless it may interfere with other functions, don't want bothered with it.

Of course, we are a fairly small company, not sure about your situation. Hasn't gotten me anywhere yet in 6 years as far as a promotion, but then again, the only person above me in the department is my boss, it is just the tow of us.

Mark
 
It is normal to be asked those questions (at least for me). Many times management does not know what they can do, neither who/how to do it. This is particulary visible on small companies, but can also happens or medium to big companies.

Many times when I was doing analysis for small/medium companies I would be aware of many things that some of the managers had never dealt with and I was many times expected to tell them that they COULD do X to improve their performance/sales/cost (you name it).



Regards

Frederico Fonseca
SysSoft Integrated Ltd
 
Part of the design process of any system should be recommending ways to improve the process and thus proposed policy changes. All too many systems have been designed to fully replace inefficent manual systems without regard to how the systems could be improved using a computerized model.

I think it our responsibility as system designers to suggest places where the existing poilicy is not the best choice in the new system. We will not, of course, win all these discussions, sometimes law or other factors dictate the policy more than efficient processing. But just by bring up the subject, we often learn more than we did about how exactly the policy must function in the final product.

However, I think it is up to us to explain were we see the policy can be improved. Remember when you are designing a new system, you often see the whole picture better than anyone else in the company because they only interact with part of it. So you will see things that others do not.

Often there are things we can do once the system is implemented that were not available before because we are collecting more information or have the ability to add it up automatically rather than manually adding from thousands of paper pages. And in the process of designing a new system, you may become much more familiar with the relevant laws or government regulations than anyone in the company was previosly (HIPPA comes to mind); therefore you may become aware of necessary policy changes that others are not yet aware of.

Additonally, an experienced programmer may be familar with the ways other companies did similar tasks and may have some suggestions based on that knowldge as well. Often, I have noticed it takes an outsider to see things that people intimately familar the current system do not see.

Questions about posting. See faq183-874
 
I think this is one of the main reasons why I became enamored with proramming. A good programmer doesn't just build a system, they review processes, make suggestions, and stay abreast of latest technology.

If I was JUST programming, I would be frustrated by now and seek another area of work.
 
Mike, What you're seeing is exactly why so many MRP/ERP installations go over budget or fail completely. Many managers don't really understand this stuff. They think commercial software, I install it and it does everything for me. They don't get the fact taht the software is flexible and it's up to THEM to decide how they want to use it. They want to just be TOLD how it's going to work.


Jeff
The future is already here - it's just not widely distributed yet...
 
Many users don't know what they want until you've delivered what they asked for.
You review the new requirements, examine a number of ways they can be met, pick the best one, test and implement it.
And then the whole thing starts over again...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top