Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw

Re: Project Management

by chunlou (Curate)
on Jul 27, 2003 at 04:24 UTC ( #278196=note: print w/replies, xml ) Need Help??

in reply to Project Management

We can think of project management embedded within the development process embedded within the business process.

Business Process
Marketing research, product idea development & positioning, sales pitch, etc. Development Process Customer support, sales pitch, etc. 
Planning, coordination, bargaining, etc. Project Management Documentation, post mortem, etc. 
Req. Elicit. & Analysis Design Coding Testing

We will only elaborate Project Management a bit more. Notice that the table above doesn't signify the processes are a linear and waterfall one. In fact, project management is usually an iterative process. We could illustrate the iterative nature by journalizing the percentage of completeness of each project management phase as below.

iteration Req. Design Coding Testing
1 80%      
2 83% 90%    
3 84% 92% 50%  
4 86% 94% 70% 10%
5 88% 97% 90% 15%
6 89% 98% 99% 50%
7 90% 99% 99% 99%

Notice, in practice, we never ever catch 100% of the bugs during testing, we might postpone the implementation and coding of certain things for whatever reasons, we might overlook something during design, and rarely do we have complete requirements for any project as requirements are constantly evolving things. Hence, no 100% anywhere.

A goal of project management is to define the "acceptable " amount of information or artifacts we should gather at each step before we should and could move on to the next step, and who's responsible for what.


Developmental Phase

Role1. Req Elicit. & Analysis:
"What to Do"
"How to Do"
"Did Right?"
Mgr/Client lead     verify
Proj Mgr/Sys Analyst lead lead buffer
Artist/Programmer (as needed) lead lead fix
QA (as needed) lead   lead
Artifacts: flowcharts,
use cases...
DB schema,
class diagram,
site map,
(prelim) test script2....
(you know
results to the
test matrix...

1.Note that a single person could take multiple roles.
2. Not everyone writes a test script during Design. But having one could provide insight. Say, if a test script gets too complicated, probably so is the app.

The table above adopted from Re: Re: XSL/XML/Perl as a development process. What "artifacts" you want to use are entirely up to you.

In practice, I found a good execution of a methodology itself is more important and challenging. Challenging because a good execution requires good cooperation and discipline and the willingness to learn. But people tend to like to do things their own way.

So, whatever project management methodology you use, make sure you secure the buy-in from your team members and your management, and the people have enough skills and knowledge to adopt the methodology, or else you're doomed, just like many other people before you.

Footnote: No one likes paper work for paper work's sake. But do keep some form of written thing (electronic, paper, clay, or whatever) to document what you're asked to do and by whom. It's of practical and legal importance.

Once two account managers looked at our developing product in process, they fumed when they noticed some "unanticipated" changes. Asked me why. I told them they told us to make the changes. They said they never did. I emailed them the email that indicated such a request was made by them. They never replied me back.

That's why management buy-in is important to your project management.

As for client involvement, showing them screenshots during requirement and design phases and asking them to play with a semi-working product during coding phase would be a good start.

But also be aware that not all clients want to be involved. Some of them are like a plain-looking woman walking into a beauty salon saying, "Make me beautiful!" and leaving you no clues as to what she really wants.

In fact, in a way, requirement elicitation is the most difficult job in project management. It requires the skill of a clinical psychologist or a psychic.

Replies are listed 'Best First'.
Re: Re: Project Management
by cleverett (Friar) on Jul 27, 2003 at 17:52 UTC
    In fact, in a way, requirement elicitation is the most difficult job in project management. It requires the skill of a clinical psychologist ...

    When you think about it, most people's internal (that is, imaginary) ideas of reality appear more real to them than reality itself, and the only corrective is pain -- like Ben Franklin said, "Experience is a harsh schoolmistress, but she's the only one fools will learn from."

    What's helped me most in that regard is a book from another discipline entirely than programming, The Structure of Magic Volume 1: A Book About Language and Therapy by Richard Bandler and John Grinder. It breaks down the actual skill of eliciting communications of fact that (competent) clinical psychologists use.

    It's also great for putting PHBs in their place, as in "What specifically do you mean, sir, by object oriented", and watching them proceed to flounder ... heh.

      Yeah, but Structure Of Magic II is more interesting...! I shows you how to ask interesting questions -- II shows ways to give interesting answers.

      You are what you think.

Re: Project Management
by rlb3 (Deacon) on Jul 27, 2003 at 11:47 UTC
    I'd like to thank everyone for there responses and their time.
    I am overwhelmed that the volume and detail of the replies.
    This is what make perlmonks one of my favorite sites.

    Thank you,

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://278196]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2017-12-17 18:59 GMT
Find Nodes?
    Voting Booth?
    What programming language do you hate the most?

    Results (466 votes). Check out past polls.