May 8, 2009 at 7:24 am
(Some musings offered for comment, criticism, additional insight or rebuttal.)
After some 50 years working in the computer field, I am becoming convinced that a major failing of the business (particularly enterprise computing) is due to an overabundance of "Overseers" getting in the way of the "Grunts"--the individual contributors that are actually doing the work.
The "Overseers" are the people who spend most of their expensive time unproductively attending crowded project planning and status meetings. The productivity of those meetings is measured in Power Point slides, rarely-read handouts and overbooked conference rooms. These folks cling to the (long since discredited) waterfall approach of implementing systems; the high ceremony overhead of big design up-front, formal design documentation, and elaborate (premature) specifications. They include project managers, specification writers, and other various and sundry "facilitators" and "coordinators". (For outsourced work, duplicate the above for both the client and contractor enterprises, and add acquisitions specialists, contract administrators, and legal staff.)
The "grunts" are the folks who actually contribute to the development effort; those who "cut code", design the system architecture, design and administer the databases, debug and test – in other words, the actual individual contributors and workers. (Even perhaps, their direct supervisors and managers, but only if those supervisors are technically qualified, could do the work themselves, and can provide valuable guidance and training to the grunts who report to them!)
In the wake of past failed projects, management's ill-considered response over the years has been to add ceremony: more big up-front high ceremony design, planners, project managers, review boards, schedulers, and extensive reporting.
My thesis is that projects would be completed faster, cheaper, and better if the overseers were replaced by more and better qualified grunts. In other words, don’t add overhead to oversee the work of unskilled or poorly trained implementers, recruit or train the grunts to be more qualified to do their work.
Here is my three-step proposed solution:
1.Adopt agile development strategies, working iteratively with the client organizations and functional (problem domain) experts, with very frequent (weekly) feature review, critique, and redesign.
2.Invest in recruiting better qualified, more experienced developers, and in training the existing development staff to raise their level of competence as necessary.
3.(The radical suggestion)--Assign multiple competing development teams working in parallel to develop the same system, fully expecting that the lower quality products will be discarded. (In all probability, the best features of all teams output will ultimately be migrated to the winning system.)
I fully expect that the total implementation cost would be significantly reduced, the quality of the completed projects would be much improved, and the shameful failure rate of IT projects finally reduced.
May 10, 2009 at 5:17 pm
What you're talking about almost sounds like a Business Intelligence project. Make a large investment, someone on faith, that putting more effort in up front will pay off later.
To a large extent I think you're right, but it's hard to find good talented people that will work well without a lot of direction. What's qualified? How many people in your company can work well independently? I'm not sure it's a majority, but it's probably more than managements thinks can. And since we're not doing a great job building applications with overseerers, maybe this makes some sense.
There's definitely a lack of trust that the grunts will keep marching in a timely manner towards goals without someone driving them. I think even when I've seen good developers that work hard, more of them will get off task and want to build something great instead of something that gets the job done.
We definitely are swinging towards the too much control side of things, but I'm not sure a free for all works better. Especially as people have as little loyalty as companies. A company doesn't want to spend a lot of time and $$ to train people that will take another job quickly (because they're talented) and lost of people don't necessarily want to invest in themselves.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
May 11, 2009 at 2:24 pm
Quite agree, however, the difficulty is in finding someone with enough technical skill to lead the grunts to ensure they don't run off on wild fancies, and at the same time has the trust of their managers to be left pretty much alone to run the project without the overseers and meddling. In my experience there are few people who can do both - either they are great technically, or great managers, but rarely both.
I have always been one of the grunts, not really having the best people skills to be a good manager, but one of the most successful (and largest) projects I have worked on I did lead the grunts from that middle ground. I think the project was successful to two reasons; firstly I had a manager who had enough faith in me to leave all the design/technical aspects in my hands, and secondly, I had a great technical team with key people I could let have autonomy in dealing with the day-to-day issues. All I had to do was simply guide the grunts, and make the really critical technical decisions.
It seems that when the overseers get too involved the playing field keeps changing, and when that happens the technical design also has to change. And that's where the trouble starts.
Chris
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply