Re: Project Management

[chunlou]

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"	Design: "How to Do"	Coding: "Do"	Testing: "Did Right?"
Mgr/Client	lead			verify
Proj Mgr/Sys Analyst	lead	lead	buffer disturbance	coordinate
Artist/Programmer	(as needed)	lead	lead	fix
QA	(as needed)	lead		lead
Artifacts:	flowcharts, screenshots, use cases...	DB schema, class diagram, site map, (prelim) test script2....	(you know what...)	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.

[cleverett]

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.

[chaoticset]

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.

[rlb3]

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,
rlb3