Project Management

From Slashdot – Is Your Development Project a Sinking Ship?

Blame the P.M. – usually (Score:5, Insightful)
by jacobcaz (91509) on Tuesday January 04, @04:38PM (#11257318)
(http://www.cazz.org/)

Every project, whether it’s a development project, implementation or business process engineering, that has failed for us has been because of poor project management. Period.

We’ve had people who didn’t know how to accurately scope business requirements, get buy in from other departments and generally “play nice” enough to keep everything running smoothly. Your P.M. needs to be able to be a hard ass, but also to be a buddy.

It boils down to excellent management skills and excellent people skills and without both you’re setting a project up for disaster. A good P.M. needs to know when to tell senior management it’s asking for the impossible too, and a good P.M. needs to know he has kung-fu so he can get away will telling senior management their idea won’t be implemented.

It’s not magical (Score:5, Interesting)
by beldraen (94534) <beldraen_sd@beld … m [‘nsd’ in gap]> on Tuesday January 04, @04:57PM (#11257549)

Having many years of successful software project management under my belt, I can tell you it boils down to two concepts: professional training and discipline.

There are a million and one books and surveys and they all say the same thing. First, there is a formal process for the development of anything (not just software). This starts with the formal documentation process and meetings to discover functional and non-functional issues. Second, there is a very strong sense by everyone to want to adjust it a little more. From senior managers who allow scope creap to managers who want steps to be cut to make up time to programmers constantly who rewrite the code because they think they can squeeze 5% more time out of a loop that runs for less than a second in a process.

Most people do not realize that in a successful formal process that the actual time in a software project that is used to build the software should amount to only about 30% of the project’s development time. The other 70% is time spent on documentation, meetings, and testing to ensure that the 30% of time used on software delevopement is actually what the company is needing. And, it is discipline that keeps people on the project process in the face of the fear of not getting the project done right. The process has to be allowed to work, both to reach a project end point and to have unobstructed process from which to learn.

The part I get a kick out of is that just because people write software or run a company that they somehow think they just ought to know why projects work. If complex systems were just so easy, why would we need formal training? After all, anyone can build a bridge successfully without training, right? I am not being hard on people, though. I had this exact same though years ago and what I figured out is that the vast majority of the software industry is so poorly trained that it doesn’t even realize that it poorly trained.

Successful software development books have been around for more than 30 years. Go read! Better than that, get a university degree. The more liberal the better. Honestly, it is worth it. Here is a good place to start: Systems Analysis and Design by Kendall and Kendall (ISBN 0-13-041571-5)

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Comments are closed.