|No such thing as a small change|
Re: Project Managementby chunlou (Curate)
|on Jul 27, 2003 at 04:24 UTC||Need Help??|
We can think of project management embedded within the development process embedded within the business process.
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.
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.
1.Note that a single person could take multiple roles.
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.
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.