|
Posted by Jerry Stuckle on 11/13/72 11:30
Andrew DeFaria wrote:
> Jerry Stuckle wrote:
>
>> Andrew DeFaria wrote:
>>
>>> Jerry Stuckle wrote:
>>>
>>> Ah that would be wonderful. But in my some 25 years in the business I
>>> don't think I've ever actually seen that in practice! Then again I do
>>> more admin/build/release stuff... (And surprisingly enough, even at
>>> that late stage of the game, rarely do I see design docs that go to
>>> the level of defining function names and parameters... Sad but true)
>>
>>
>> Then you're Project Manager is not managing the project properly.
>
>
> Then my Project Managers, from over 25 years - at companies as big and
> diverse as HP, Sun, Cisco, Amerquest, Broadcom and a plethora of others
> (look up my resume...) have all not been managing their projects
> properly. This does say something very loudly and clearly - what you
> describe is definitely not the norm. Indeed what you describe is pie in
> the sky rarity!
>
Yep, I find that very common in the business world today. Just because
you're big doesn't mean you can manage projects properly. I saw the
same thing when I worked for IBM. It's one of the reasons I left IBM.
They taught me project management, and I worked on a couple of projects
where it was used quite effectively. Then I got stuck on one which was
doomed to fail because it wasn't being managed properly. I had the
chance to get out, so I took it.
What percentage of these projects were late, over budget and/or never
got finished at all? And how many were finished but didn't provide the
functionality required? Quite frankly, the result is a surprisingly
high percentage.
This, BTW, includes the project I was on when I left IBM. It was
supposed to be a six month project. It actually should have taken less
than that. But after two years it was canceled.
But some companies are seeing the light. And those projects are
succeeding. They are on time, within budget and successful.
> Mind you I agree with the philosophy and personally that's the way I
> would do it. However, and again, that is not the way I've ever seen it
> done.
>
That's where as a consultant I have an advantage. If the customer wants
me, it's on my terms. And my track record shows I can get the work done.
> Finally, my Project Managers as of late are not really projects managers
> as per se, rather they are clients.
>
Clients are not project managers. They are clients. Two entirely
different things!
>> I learned about project management when I was working for IBM back in
>> the 80's.
>
>
> Break out the blue suit and tie... ;-)
>
You forgot the white shirt! :-)
>> Since then I've been both a programmer and a PM. When I've been a PM,
>> the documentation is complete long before programming starts (and yes,
>> I get the programmers involved in the design). And I've been a
>> programmer on projects where the design is done properly. Every one
>> was completed on time
>
>
> Given enough time that is. Unfortunately businesses do not really have
> that kind of time anymore. Models like the Open Source model beat the
> pants off of the structured design everything first then start coding
> methodologies of the past...
>
Proper project management *shortens* the time it takes to complete a
project - the bigger the project, the more time it saves.
When the design is done ahead of time, there is less rewriting because
other code changed. And every time you have to rewrite the code, you
increase the chance of errors creeping into the code, which means more
test/diagnosis/correction time. It also increases the number of errors
which can make it to the customer.
>> and within budget, given reasonable time and budgetary constraints.
>
>
> Aye there's the rub - "reasonable time". Which is way longer than is
> acceptable these days. Why do you think IBM fell from on high? Because
> different more flexible and a lot faster ways of doing things developed
> and IBM didn't keep pace. The only reason IBM is back at all is that
> they have actively changed their culture and stringentness.
>
All the more reason to do proper management.
And no, IBM didn't keep pace. They didn't realize the effect their PC
would have on the rest of the world. They made major missteps in their
target audience. They did a huge amount of things wrong.
>> And change orders were handled by modifying the design - which showed
>> exactly how it would affect other parts of the project.
>>
>> I've also worked on ones where PM wasn't properly done. Some were on
>> time, but most were late. They also had more bugs and change orders
>> were harder to implement.
>
>
> The track records of the big companies has not agreed with your assessment.
>
As I said - just because you're big doesn't mean you do it right. And
the track record of the big companies has shown that it has been done.
I used to do a lot of training - both in programming and project
management. Most of my customers were from the Fortune 1000 list. And
virtually every class where I asked if they had projects which were
overdue, over budget, etc., I had people raise their hands. And the
common thread was that the projects were not being managed.
I actually had a manager tell me one time "If my programmers aren't
writing code, they aren't being productive." He completely ignored the
fact that just because they were writing code *did not* mean they were
being productive! It meant they were writing code.
But without direction, the manager had no idea of the code would ever be
used in a project or not. And if it was not, they weren't very
productive, were they?
It's why I get programmers involved with the design phase. They are
helping, and more importantly, they are getting a better feel for the
project as a whole. And they are being productive - they are helping to
produce the design spec they will eventually write code for.
And when it comes time to write the code, they do it more quickly and
with fewer errors because they don't have to keep going back and
rewriting it.
>>>> Of course, if you don't design the application and fly by the seat
>>>> of your pants, that's another story.
>>>
>>>
>>> In my line of work I'm forced to do that all the time...
>>
>>
>> I've heard that before. But all but the smallest projects benefit
>> from a proper design.
>
>
> Yes but then your contract expires early and your out on the street
> begging for food. You know those grandiose ideas and methodologies look
> great on paper. But the real world and real business constraints always
> seem to get in way. As a contract and a businessman myself I strive to
> keep the customer happy and they are always right, etc... Real world is,
> while proper design, etc. is all nice, it don't happen much.
>
>
I admit, when I first started consulting, I was hungry a fair amount of
the time. But never since then. In fact, I've turned down work.
Success breeds success - and demand.
The only "real world and real business constraints" here is the thinking
of management. You need to convince them that proper management means a
more successful project. This takes proven experience, knowledge and
belief in yourself, amongst other things. And most importantly, it
takes skill in dealing with the customer.
Probably the best lesson I ever learned was to walk away from a bad
contract instead of taking it, no matter how hungry I was.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|