Reason 1: No Spam
Your gmail account has efficient spam filters. In hotmail, i time and again got spam, and yahoo is even worse. In gmail, spam messages in my inbox are rare.
Reason 2: Better filters
Im gmail, you can set many autofilters which are not available in hotmail. True, with hotmail/livemail you can create a filter to automatically move an email to a folder. You can search the topic or the addressline. I dont see an option to search the body of an email.
Reason 3: Labels
In gmail, you can attach one or more labels to an email. Labels are different from folders. An email can be in only one folder, but may have more than one label. For example, if you are a member of a political party, and also an environment acivist, you would have to sort emails which concern both in one of them.
But then it is out of your inbox, and out of sight. With gmail labels, you can automatically attack a label, or autoarchive it, just as you please.
Gmail can automatically add labels based on both the topic and the contents of an email.
Reason 4: More Space
Hotmail gives you 5Gb, and Gmail 6.x (at the moment of writing) and growing daily.
Reason 5: Threading
Gmail groups emails in threads. In your inbox, you see the names of the threads (subjects of your emails) and the number of messages in the thread. When you open a thread, gmail displays all old messages as collapsed, while the first unread message is showed open. A great time saver.
Reason 6: Less is more.
Gmail has less distracting adds, it has less chrome, less images, less colors and is thus easier to use. Your mind is less distracted and has to search less.
Reason 7: Archive, dont delete.
With growing archive space, Gmail encourages you to arcghive instead of deleting messages. Virtually all hotmail users i know delete their messages instead of moving them to folders.
Reason 8: Dont expire.
Dont use your hotmail account for a month and you have lost your emails, including those holidy pix, including that valuable family photo, including that emailed password. No doubt Gmail has some expiration limit too, but i havent seen my emails deleted when i forgot to access my account for 1 month.
Reason 9: Variations in name.
If your emailaddress is JohnJohnsson@gmail.com, you can send an email to JohnJohnsson+testexpert@gmail.com and it will arrive in your normal email box. But you can use that extra "+testexpert" to automatically attach a label. Sending the same to hotmail results in "it was rejected by the recipient domain". This is also very convenient when signing up for a service somewhere on the web - you can find emails related to their service in your normal archive by searching for this email address.
Reason 10: Better security.
Need i say anything?
No ads
Live mail adds advertisements to the bottom of your email - gmail doesnt
Monday, April 21, 2008
Tuesday, April 15, 2008
Stakeholders - how to model them
UML is all about visual modelling, and though Unified Process has made UML the default modelling technique, it does not visually define stakeholders or their relation to the stakeholder requests.
Personally I find this a shortcoming, and I have been thinking about ways to model stakeholders, their types, their relations and their interests in stakeholders requests.
Stakeholder analysis is a rapidly growing area wth its main applications in politics and management. For RUP purposes, we usually don't need to model all properties and relations between stakeholders. Moreover, as circulstances, and thus stakeholders, can change frequently, it is often not very wise too spend too much time and effort on stakeholder analysis, as many projects should and will be short.
But for Requirements Management it is wise to link Use Cases to stakeholder requests, and Stakeholder requests to Stakeholders. By linking Use Cases to Stakeholder Requests, we can check that no Use Cases creep in that are not supported by Stakeholder requests. By linking Stakeholder requests to Stakeholders, we can make sure that these Use cases are requested by at least one Stakeholder.
"Traditionally" (for what is tradition in this young branch?) stakeholders and feature requests are related in a matrix. But tables are not very intuitive. It will have benefits if we can model the relations visually.
The simplest representation of a link between stakeholder and feature request or stakeholder request is a line. Like the Use Case Model, a Stakeholder Request Model could consist of persons (stakeholders) linked to ovals (feature requests) by lines.
As the lines should depict support of a stakeholder for a request, lines should be uni-directional and thus have an arrow.
The power of stakeholders is often described as an important feature, and something we could visually depict by the size of the person representing a stakeholder. To keep things manageble, 3 levels (powerful, normal, weak) should suffice.
The support of a stakeholder for a request can be depicted by the widt of a line, the thicker the line, the stronger the support. Again, 3 levels should be sufficient: Must, Should, Could, they correspond with the first three levels of MosCow:
In a good project, the Wonts wont be present.
Let me conclude this with a simple example of what i have in mind:
This example shows part of an online registration system for courses / lectures. Professors may register a lecture they intend to give, students may sign up for them. The manager provides the funds for the system, holds the most power (hence drawn larger) and has the largest influence.
The analyst, knowing this, might do well to have a 5 minute chat with the manager before starting the work on a use case to ask him what the priorities of the manager are, before going into the details with the student or the professor. If the managers respons is: "the students will have to use the system anyway, so dont spend to much money on their facilities", he has another frame of mind than if the manager would reply: "At present, too many students find it hard to sign up in time for the start of courses and that holds the results of our university back".
Sources:
Personally I find this a shortcoming, and I have been thinking about ways to model stakeholders, their types, their relations and their interests in stakeholders requests.
Stakeholder analysis is a rapidly growing area wth its main applications in politics and management. For RUP purposes, we usually don't need to model all properties and relations between stakeholders. Moreover, as circulstances, and thus stakeholders, can change frequently, it is often not very wise too spend too much time and effort on stakeholder analysis, as many projects should and will be short.
But for Requirements Management it is wise to link Use Cases to stakeholder requests, and Stakeholder requests to Stakeholders. By linking Use Cases to Stakeholder Requests, we can check that no Use Cases creep in that are not supported by Stakeholder requests. By linking Stakeholder requests to Stakeholders, we can make sure that these Use cases are requested by at least one Stakeholder.
"Traditionally" (for what is tradition in this young branch?) stakeholders and feature requests are related in a matrix. But tables are not very intuitive. It will have benefits if we can model the relations visually.
The simplest representation of a link between stakeholder and feature request or stakeholder request is a line. Like the Use Case Model, a Stakeholder Request Model could consist of persons (stakeholders) linked to ovals (feature requests) by lines.
As the lines should depict support of a stakeholder for a request, lines should be uni-directional and thus have an arrow.
The power of stakeholders is often described as an important feature, and something we could visually depict by the size of the person representing a stakeholder. To keep things manageble, 3 levels (powerful, normal, weak) should suffice.
The support of a stakeholder for a request can be depicted by the widt of a line, the thicker the line, the stronger the support. Again, 3 levels should be sufficient: Must, Should, Could, they correspond with the first three levels of MosCow:
- M - MUST have this.
- S - SHOULD have this if at all possible.
- C - COULD have this if it does not affect anything else.
- W - WON'T have this time but WOULD like in the future.
In a good project, the Wonts wont be present.
Let me conclude this with a simple example of what i have in mind:
This example shows part of an online registration system for courses / lectures. Professors may register a lecture they intend to give, students may sign up for them. The manager provides the funds for the system, holds the most power (hence drawn larger) and has the largest influence.
The analyst, knowing this, might do well to have a 5 minute chat with the manager before starting the work on a use case to ask him what the priorities of the manager are, before going into the details with the student or the professor. If the managers respons is: "the students will have to use the system anyway, so dont spend to much money on their facilities", he has another frame of mind than if the manager would reply: "At present, too many students find it hard to sign up in time for the start of courses and that holds the results of our university back".
Sources:
- Stakeholder analysis: a review, 2000, Oxford University press, Ruairí Brugha1 and Zsuzsa Varvasovszky2
- Cultivating Peace: Conflict and Collaboration in Natural Resource, 1999, World
Bank Institute,Ricardo Ramirez - http://en.wikipedia.org/wiki/MoSCoW_Method
Stakeholders - who are my stakeholders?
One of the Rational Unified Process (RUP) concepts is that of a stakeholder.
At Agilemodelling Scott W. Ambler describes stakeholders as:
My definition of a project stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, the "gold owner" who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project.
The author explicitly does not include the developers working on the project. In my humble opinion, a right decision.
My problem with this definition is that it is not a definition, it is a list. My definition would be:
Someone is a stakeholder if that person has an interest in the result of the project.
Note that this definition does not say that the stakeholder has an interest in the project. That would make everyone involved in the project a stakeholder. But that would make the project an aim in itself.
This definition also transcends the terms of software development. It can be applied to any project in any branch.
Stakeholders are important during the project process, because they:
* In the conception phase, define the scope of the project (they define the requested features list)
* During the elaboration phase, stakeholders have to agree that the current vision can be achieved if the current plan is executed
* During both elaboration phase and during the construction phase, the stakeholders need to guard the agreed balance of features
* At the end of the construction phase, the stakeholders have to say if they are ready to move to the transition phase.
* In all phases, stakeholders are essential for analists as a source of information.
Stakeholders typically will have to guard their own interest. Depending in the project management organization choosen, a project board may be
formed where they meet and discuss the priorities of the project.
Examples of stakeholders are:
* The funder of the project. Often there is one manager paying for the project. Sometimes there is more than one organization or department that funds a project. Conflicts between these parties should not drip down into the project. The project board should balance te interests by having the stakeholders agree on the scope through the adoption of a Requested Features List.
* Users. But be aware: "The user" does not exist. More than one department will be involved. More than one type of user will be involved. If there are large differences, they will be more than one stakeholder.
* IT staff who will have to work with the software after delivery. Examples are maintenance personel, helpdesk, dba-ers
Stakeholders will often be represented by people. The funder of the project will often send someone else to represent his interests, for example his sale manager or his CFO.
The users may be represented by several people, depending on the size of the users group and the diversity of their roles.
The Getronics Delivery Process, a company based implementation, says "Assign one or more staff members to perform this role only" before proceeding to combine this role with several others. The decision to assign staff members instead of line personel is a doubtful one.
There are several types of Stakeholders, and several roles. Ons distiguishment which is important to make is that some Stakeholders are Actors, while others are not. For example, a student who will use the Course Registration System to sign up for a course is both a Stakeholder and an Actor. The university director who finances the realization of a Course Registration System will be a Stakeholder, but probably not an Actor, unless he also lectures.
At Changing minds.org the authors view a short list of roles:
The first group they distiguish, the Sponsors, is a very important one.
In the past 2 decades there have been several research projects into stakeholder analysis. Important work has been done by:
Stakeholders can be classified in several ways. According to wikipedia, some of the commonly used 'dimensions' include:
At Agilemodelling Scott W. Ambler describes stakeholders as:
My definition of a project stakeholder is anyone who is a direct user, indirect user, manager of users, senior manager, operations staff member, the "gold owner" who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, or maintenance professionals potentially affected by the development and/or deployment of a software project.
The author explicitly does not include the developers working on the project. In my humble opinion, a right decision.
My problem with this definition is that it is not a definition, it is a list. My definition would be:
Someone is a stakeholder if that person has an interest in the result of the project.
Note that this definition does not say that the stakeholder has an interest in the project. That would make everyone involved in the project a stakeholder. But that would make the project an aim in itself.
This definition also transcends the terms of software development. It can be applied to any project in any branch.
Stakeholders are important during the project process, because they:
* In the conception phase, define the scope of the project (they define the requested features list)
* During the elaboration phase, stakeholders have to agree that the current vision can be achieved if the current plan is executed
* During both elaboration phase and during the construction phase, the stakeholders need to guard the agreed balance of features
* At the end of the construction phase, the stakeholders have to say if they are ready to move to the transition phase.
* In all phases, stakeholders are essential for analists as a source of information.
Stakeholders typically will have to guard their own interest. Depending in the project management organization choosen, a project board may be
formed where they meet and discuss the priorities of the project.
Examples of stakeholders are:
* The funder of the project. Often there is one manager paying for the project. Sometimes there is more than one organization or department that funds a project. Conflicts between these parties should not drip down into the project. The project board should balance te interests by having the stakeholders agree on the scope through the adoption of a Requested Features List.
* Users. But be aware: "The user" does not exist. More than one department will be involved. More than one type of user will be involved. If there are large differences, they will be more than one stakeholder.
* IT staff who will have to work with the software after delivery. Examples are maintenance personel, helpdesk, dba-ers
Stakeholders will often be represented by people. The funder of the project will often send someone else to represent his interests, for example his sale manager or his CFO.
The users may be represented by several people, depending on the size of the users group and the diversity of their roles.
The Getronics Delivery Process, a company based implementation, says "Assign one or more staff members to perform this role only" before proceeding to combine this role with several others. The decision to assign staff members instead of line personel is a doubtful one.
There are several types of Stakeholders, and several roles. Ons distiguishment which is important to make is that some Stakeholders are Actors, while others are not. For example, a student who will use the Course Registration System to sign up for a course is both a Stakeholder and an Actor. The university director who finances the realization of a Course Registration System will be a Stakeholder, but probably not an Actor, unless he also lectures.
At Changing minds.org the authors view a short list of roles:
- Sponsors
- Targets
- Others affected
- Partners
The first group they distiguish, the Sponsors, is a very important one.
In the past 2 decades there have been several research projects into stakeholder analysis. Important work has been done by:
- Mitchell, Agle et al. 1997. They identify Stakeholders based on 3 properties: power, legitimacy and urgency.
- Fletcher, Guthrie et al. 2003
- Turner, Kristoffer and Thurloway, 2002
- Ronald K. Mitchell, Bradley R. Agle and Donna J. Wood, 2002
Stakeholders can be classified in several ways. According to wikipedia, some of the commonly used 'dimensions' include:
- Power (high, medium, low)
- Support (positive, neutral, negative)
- Influence (high or low)
- Interest (high or low)
- Attitude (supportive or obstructive)
Tuesday, April 08, 2008
Open office
An email announcing the availability of Open Office 2.4 had arrived while for a day i didnt check my gmail.
Allthough i rarely browse through the new features list, this time and did. And one thing caught my eye: Open office seems to be moving towards google. Google has always had a penchant for open source. They always rated wikipedia quit high in their results lists, though i dont know if this is a by-product of their existing algorithm or something that they awarded extra weight on purpose.
Some examples of their movement towards google:
* OpenOffice.org2GoogleDocs - the name suggests it becomes easy to transfer open office documents in google docs. Google docs already could import open office documents, this will make 2 way traffic easier.
* The writers tools have several extras. One is an integration with Google Translate
* Another writers tools feature is an integration with google maps
One wonders if this is a signal of closer cooperation between google and sun corporations.
Allthough i rarely browse through the new features list, this time and did. And one thing caught my eye: Open office seems to be moving towards google. Google has always had a penchant for open source. They always rated wikipedia quit high in their results lists, though i dont know if this is a by-product of their existing algorithm or something that they awarded extra weight on purpose.
Some examples of their movement towards google:
* OpenOffice.org2GoogleDocs - the name suggests it becomes easy to transfer open office documents in google docs. Google docs already could import open office documents, this will make 2 way traffic easier.
* The writers tools have several extras. One is an integration with Google Translate
* Another writers tools feature is an integration with google maps
One wonders if this is a signal of closer cooperation between google and sun corporations.
Subscribe to:
Posts (Atom)