Four Aspects of Project Communication
I've been thinking about successful project
management. Not from the timeline and budget aspect though what I'm thinking
about helps to assure success in that way too, but from a "what are the
fundamentals that you need to establish early on if you are going to be
successful" way. I've come up with four things: (1) Language, (2) Vocabulary,
(3) Process and (4) Methodology.
I think that one of the first tasks of a project
should be to establish these four corners of operation.
First, what language will we use. My current favorite for a lot of the projects that I am working on is UML - Unified Modeling Language . UML provides a common set of artifacts for describing many of the attributes of project. To quote the site above, "The Unified Modeling Language™ (UML) is the industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems."
Second, we need a common vocabulary. Think of the word "port". Port has many meanings: a harbor for ships, a sweet wine, a connector on computer, an address for communication (HTTP is on Port 80), to transfer from one system to another. It is crucial that vocabulary terms get defined and published as the project moves along so that everyone (programmers, architects, stake holders, customers) understand what is being expressed in the language they see.
Third, a process for the project to follow should be determined and explained early. This establishes, early on, what the expectations are for each of the steps of the project. My current favorite is the Enterprise Unified Process or EUP . The EUP talks about what deliverables are expected in each step of the process. The EUP is also concerned with whole product life-cycle birth-to-death. If you think about phasing out a product up front, then maybe the way you store data will be different. If you know the life-cycle is one year, then maybe you spend much less time on user interface issues. If you think you will need the product for 5 years, then expandability, portability and flexibility will be critical. EUP is expressly iterative. This means that if you state early on that you will be following the EUP, then everyone knows that you will come back and do some things over.
Finally, you need a methodology. How will we go about documenting the vocabulary, developing the UML and following the EUP. Once again, my favorite is Agile Modeling . In Agile Modeling, you assume that everything is iterative and that things change. You make only the documents that you need and you make them only as well as you have to. If a picture of a white board works, use it. Don't move things to a drawing tool until you need to otherwise you will have to do all of your edits in the drawing tool, then print, then photocopy, then distribute, then get red-line edits back, then redo the drawing, then.... You get the picture. Keep things light and flexible. You know you will have to change the documents so keep them changeable. Use postit notes on chart paper until you have nailed things down fairly well.
There are a lot of good resources on UML, EUP, and Agile Modeling. Work early on with your team, your stake-holders and customers to explain to them (and convince them) the Language, the Vocabulary, the Process and the Methodology. If you do, you will set up communications and control expectations right from the start. This will mean the project has a better chance for gathering and documenting the correct requirements, do the right steps in the right order and having everyone understanding what they are talking about and working on. That is a good start towards success in the other way -- an on-time on-budget project.
First, what language will we use. My current favorite for a lot of the projects that I am working on is UML - Unified Modeling Language . UML provides a common set of artifacts for describing many of the attributes of project. To quote the site above, "The Unified Modeling Language™ (UML) is the industry-standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems."
Second, we need a common vocabulary. Think of the word "port". Port has many meanings: a harbor for ships, a sweet wine, a connector on computer, an address for communication (HTTP is on Port 80), to transfer from one system to another. It is crucial that vocabulary terms get defined and published as the project moves along so that everyone (programmers, architects, stake holders, customers) understand what is being expressed in the language they see.
Third, a process for the project to follow should be determined and explained early. This establishes, early on, what the expectations are for each of the steps of the project. My current favorite is the Enterprise Unified Process or EUP . The EUP talks about what deliverables are expected in each step of the process. The EUP is also concerned with whole product life-cycle birth-to-death. If you think about phasing out a product up front, then maybe the way you store data will be different. If you know the life-cycle is one year, then maybe you spend much less time on user interface issues. If you think you will need the product for 5 years, then expandability, portability and flexibility will be critical. EUP is expressly iterative. This means that if you state early on that you will be following the EUP, then everyone knows that you will come back and do some things over.
Finally, you need a methodology. How will we go about documenting the vocabulary, developing the UML and following the EUP. Once again, my favorite is Agile Modeling . In Agile Modeling, you assume that everything is iterative and that things change. You make only the documents that you need and you make them only as well as you have to. If a picture of a white board works, use it. Don't move things to a drawing tool until you need to otherwise you will have to do all of your edits in the drawing tool, then print, then photocopy, then distribute, then get red-line edits back, then redo the drawing, then.... You get the picture. Keep things light and flexible. You know you will have to change the documents so keep them changeable. Use postit notes on chart paper until you have nailed things down fairly well.
There are a lot of good resources on UML, EUP, and Agile Modeling. Work early on with your team, your stake-holders and customers to explain to them (and convince them) the Language, the Vocabulary, the Process and the Methodology. If you do, you will set up communications and control expectations right from the start. This will mean the project has a better chance for gathering and documenting the correct requirements, do the right steps in the right order and having everyone understanding what they are talking about and working on. That is a good start towards success in the other way -- an on-time on-budget project.
Posted: Fri - July 11, 2003 at 04:56 PM
