|
|
Posted by Andrew DeFaria on 11/13/40 11:30
Jerry Stuckle wrote:
>> 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.
What does that say to you?
> Just because you're big doesn't mean you can manage projects properly.
At least by your definition. Granted some places have bad project
management. But many of them work just fine in ways other than what you
are espousing.
>> 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!
Didn't I just say that!
>> 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.
Agreed. Proper project management is a good thing. Is proper project
management where ever last stitch of documentation is written before the
first line of code is written. In my experience no, that is not the
case. Prototyping is more effective.
> 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.
There are many people who disagree with your theory.
>>> 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.
What I'm saying is that it's similar to a 50% off sale. What is a 50%
off sale when the seller first marks it up 100%. Answer it's a 50% gain
for the seller! You can scope out the project for 1 year and manage it
effectively and even up in at 11 months. Or you can get cracking at be
done in 7 months. How is claiming that this "proper project management"
saved 1 month of development time helpful?
>>> 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 agree. Just because you're big doesn't mean that you do it right.
However, again, every company that I have been, including big, named
companies, operate similarly and do not operate the way you say you do.
That says something. Had I just said "Well none of the companies I've
worked at do it that way" you'd say I must have worked at bad companies.
I don't think that I have.
> I used to do a lot of training - both in programming and project
> management.
Ah, those that do do, those that can't teach... :-)
> 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.
Projects need to be managed. Granted. I thought we were discussing the
way they are managed. Specifically I thought we were talking about the
requirement to have all the documentation in before coding. In practice
that rarely happens. Why is that? Just everybody doing it wrong? I doubt it!
> 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.
Actually he is correct and you are wrong. A programmers job is to write
code. I designers job is to design stuff. The programmers should be
writing code or they are not doing their job - period. They should be
writing code that was designed by the designer last month, for example.
> 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?
You assume that they are writing code for something that has not been
designed yet. Next invalid assumption!
> 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.
Granted, most programmers are not only coders, they are designers too.
> 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.
That's just what unexperienced programmers do. They need that helping hand.
>>>>> 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.
A proper consultant does what the contract requires. If the contract
does not require a large over management of a project then you shouldn't
be doing that. If the contract merely wants you to write code then you
write code. You do what you client wants.
> The only "real world and real business constraints" here is the
> thinking of management.
Yeah right! Just ignore reality. It doesn't really exist.
> 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.
So you sell them a bill of goods. Great. I'm sure it makes you money.
> 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.
--
Will the information superhighway have any rest stops?
Navigation:
[Reply to this message]
|