I am liking the idea of outlining a core set of project artifacts, whose creation are beneficial to a projects focus. With each of these artifacts you should install a quality measurement. First I am going to talk about some of these artifacts, then I will examine some measures of quality to go with them..
Goals
Goals are the first artifact I want to talk about. They are usually the driving force in getting a project up and going.
Set goals for the project. What is it you are accomplishing by completing the project? Goals and business objectives are the same thing. The worst thing that could happen when goal setting would be to name a single goal like "finish X". A goal like this says that the project is not being taken seriously and that nobody is really analyzing it's purpose. Since goals are really the first artifact of a project they should be done well, right? Many parties may be effected by a project. Shouldn't this be considered in your set of goals? (NOTE: These parties are often the users of a project's products, i.e. customers)
Sadly many projects are built on poor goal setting. If you don't clearly expose the project's goals you can very easily lose sight of the purpose in your project.
There are at least two default goals for every project. Number one is get the project done as quickly as possible and the second is quality shall not compromised. Goals can help you to know when you are going off the radar for a project. If an aspect of the project can not be reasoned as building towards one or more project goals then it should not be part of the project. That simple. Goals can help cut out a majority of feature creep. The other big help from goals is to measure the success of a project after completion. Everyone should do this. It rarely happens. I will go into that more later in this post.
Here is a (long) simple example...
You have a project for creating an application. It will be used for signing up to play on your companies inter mural sport teams. The big goal is: "make an application that is accessible by every employee across your company intra net". Another goal is: "get rid of paper sign ups, and centralize the data in a database for documentation and reuse".
Lets look at a good system requirement: "the application shall be web based". Using a web application for this makes sense. It will make the application very accessible. That helps to meet the big goal. Great. Now let's keep going with these requirements. You create the system requirement: "Use Ruby on Rails for web application platform". Your team is very familiar with Rails and therefore it makes sense to use it for creating the web platform. Both these system requirements also work with the second goal, mainly to have things backed up in a database.
Now lets look at going off of the radar. One of the new guys on the project is really into learning AJAX. He is like "Hey this will make the application so much cooler!". You and your team do not have any experience with AJAX, therefore using it would require battling a learning curve. This guy wants the system requirement: "Use AJAX to make application more responsive". Which goal does it help to accomplish. None. And in fact it would be violating goal numero uno, which is to get the project done as quickly as possible. This is something that would be nice to have but does not meet any goals.
Now if a goal of the project was: "garner new experience in the Web 2.0 domain" (yes this is generic), then you could reason using AJAX techniques in the project. Unfortunately it is rare that these type of things are included into a project's goals. This is because the person(s) setting the goals are very focused on goal #1, getting things done. Often it is hard to rationalize time spent on learning new things.
Now going back to the section above on good requirements for our goals. What if your team was not familiar with Rails, or any other web application platform (LAMP, J2EE, etc.) for that matter? Maybe you and your team have some Java Swing GUI experience. You figure "hey making a GUI based application won't be too hard". But then you think "oh yeah but getting the applications to connect to a central data store across the whole company...". If doing a web application is the best way to accomplish our goals, then you need a web platform (such as Rails). Taking the time to learn the new platform is key to the project and therefore it is not a violation of rule #1.
In this case there better be one or more goals concerned with learning and using Rails in the project. The business owners in this project would not care so much about these goals. These goals are specific to the engineering domain. The business owner would have to trust that they are necessary. When the project is done you should be able to look at the goals related to working with Rails and know if you met them and/or went outside of them. A goal would be "able to demonstrate good MVC principles in application design using Rails". These goals should narrow the focus of what is being learned to accomplish the project. Remember no AJAX ;)
Goal creation and documentation
You must create the goals and document them. Concise technical writing will almost always beat out spoken word for clarity. Let's say you come up with some goals in a project kickoff meeting. Thats great, but if you don't have a process to document them why bother with the meeting. In a week or two when you and other project members are busy on other things you either won't remember these goals, or worse interpret what they where incorrectly. All you will likely remember is "Get project X done"!
By documenting the goals you should be able to translate and connect them with every other project artifacts. When you look at the business requirements gathered for a project you should be able to easily superimpose the goals over them, and see the interconnections. This principle applies to the finished product to. The product for a project should map very easily to the goals that fostered it.
Goals should be written as clearly and concisely as possible. Most goals should be understandable by persons of varying technical background. Technical aspects related to a goal should be boiled down, with the meat found in the requirements which correspond to the goal. Sometimes goals will be more technical because of the audience. They should still be boiled down to make their purpose clear to as many persons as is possible.
Goal artifact quality
So for the 'goals' artifact here are some quality markers off the top of my head:
- Each goal clearly identifies its target area such as generate revenue or business, or create new technology. It may help to group like goals when you document them.
- The goals are written concisely, with a general, non-technical audience in mind. This does not mean a goal cannot be technical, just that it should be as non-technical as is possible.
- The goals should be clear enough so when laying out requirements for a project, you are able to validate each requirement versus one or more of the goals without confusion.
- When the project is finished (or maybe at a milestone) you should be able to draw clear comparisons between the goals and the finished product/milestone.
Goal Assessment (the next artifact)
Why even have goals? We already talked about how they can help keep focus up, and cut down on feature creep. They obviously play a huge part in the requirements gathering process. I would say goals also allow us to gauge our success. This payoff comes mostly after a project is completed. When a product is delivered one can critique it, drawing conclusions about success from how well each goal was accomplished. This critique is part of the documentation. It is an artifact I would call "The goal assessment". It should be done in a way that draws comparisons between the goals and the product's features. On each goal there should be information on what helped or hurt the accomplishing of the goal. If a product feature does not meet the goal(s) then there should be information on how it does not meet the goal, and why that is.
Now going back to the bad case, where you have one goal "Finish project X!". How the heck can you critique this? You can't. All you can do is rubber stamp the project as 'done'. With no clear documentation on the project's goals you can't do a thorough examination after completion. You are done because you have met the basic idea of what the project was supposed to be. You may have nailed the project's product, but you do not have a clearly documented picture of what has been accomplished.
Documenting the goals, and how well those goals where met, has future implications to all projects. When working on later projects you can use these goals to know what has been done and how successful it was. You can examine what made things successful. You can look for tough areas by examining the goals that could not be completed, or that where very hard to complete. If you are working on increasing quality in a particular area you should start by finding related goals on projects past. You can use the data collected about these goals to help in understanding how to increase quality.
Let us imagine a company that builds radios. They finish a project for a brand new radio machine. One of the goals of this project was to develop and implement better radio reception. They test the newly built product against older products they have built. When people listen to the new radio it is a an obvious to them that the sound is more clear and crisp. The company is happy. Now at the end of the project they have accomplished one of their goals. They should take the opportunity to examine what was done correctly to make this a success.
For the goal given above; they may document that a new electronic part came into production that made the job possible. In general to all goals, maybe they worked 50 hours a week, rather than the 40 they normally would have.
Documenting information like the above in a goal assessment allows you to see the good and bad. When going back and reviewing this a year later you would want to be re-reminded of some of the things you had forgotten.
Goal assessment quality
Here is another quick top of the head list for quality in this artifact:
- Collected information is easy to understand.
- Each piece of information is connected to one or more goals, or possibly is general enough to connect with all goals (such as the working extra hours example above).
- Nothing should be barred from this assessment. If you think a project members input is silly still put it in. If someone says the broken coffee pot caused work to slow down, they may be serious.
No comments:
Post a Comment