Tuesday, February 27, 2007
How Can I Take a Vacation
I started to think about vacations. Let's say I take a two week vacation...what happens to the project during that time assuming I am using tw0 week sprints? In the old waterfall methodology with fewer updates to management it may have somewhat invisible. In an Agile environment with two week iterations it would be very visible.
Monday, February 26, 2007
Project Factsheet
One areas I have found is not well supported from most agile processes is distributing clear, concise information to stakeholders.
The burndown chart is vital in Agile and does provide descent information on a project, but I find it lacks the depth of the providing typical information to customers that they are typically incline d to ask for.
hence, the reason for what I have termed the project factsheet. The PF, if a conglomeration of statistical information that has 2 purposes, 1) better inform the customers, 2) better acclimate project teams and projects to model process in a more agile perspective.
Take a look and give any feedback.
The burndown chart is vital in Agile and does provide descent information on a project, but I find it lacks the depth of the providing typical information to customers that they are typically incline d to ask for.
hence, the reason for what I have termed the project factsheet. The PF, if a conglomeration of statistical information that has 2 purposes, 1) better inform the customers, 2) better acclimate project teams and projects to model process in a more agile perspective.
Take a look and give any feedback.
Sunday, February 25, 2007
Detail, Shmetail....
What's wrong with fully detailed and comprehensive requirements? Plenty.
Well for starters requirements change. Stakeholders will change their minds throughout the project, because their needs have changed or because once they've seen what you've built, they realize that it is nothing like they thought it should be.
Stakeholders will ask for everything and anything. They are highly motivated to tell you everything that they might possibly want, because they may not get another chance. Therefore, the requirements include the kitchen sink within the features, resulting in higher development and maintenance time and costs.
It takes longer to develop, deploy and gain from your investment. By taking the time to define all of the requirements up front, you forgo the opportunity to focus on implementing the highest-priority requirements right now and hit the streets with something that could be used tomorrow. Therefore, your customer misses out on the benefits that would have gained earlier.
As anti project as many may think change is, it really is only change prevention and probably your number one cause of project dissatisfaction. Once you baseline your requirements, you need to assure even changing the font of a document flows through a highly complex CM model that only you and a handful of process geeks understand to ensure that your project doesn't suffer from scope creep.
Traditional change management processes usually involve a group of people—a change control board (CCB)—mysteriously lead in most cases by the Manager of the project. This group will spend considerable time (and money) to decide whether your change will pass through the saintly process of an allowed change. These processes typically take days and in many companies weeks to process a potential change.
So before you enter into requirements management, or change management give consideration on what you are writing and why, also what you are trying to prevent and why. Do you really care as a PM if your stakeholders ask for change, do you really need to enforce your judgement on the situation?
Well for starters requirements change. Stakeholders will change their minds throughout the project, because their needs have changed or because once they've seen what you've built, they realize that it is nothing like they thought it should be.
Stakeholders will ask for everything and anything. They are highly motivated to tell you everything that they might possibly want, because they may not get another chance. Therefore, the requirements include the kitchen sink within the features, resulting in higher development and maintenance time and costs.
It takes longer to develop, deploy and gain from your investment. By taking the time to define all of the requirements up front, you forgo the opportunity to focus on implementing the highest-priority requirements right now and hit the streets with something that could be used tomorrow. Therefore, your customer misses out on the benefits that would have gained earlier.
As anti project as many may think change is, it really is only change prevention and probably your number one cause of project dissatisfaction. Once you baseline your requirements, you need to assure even changing the font of a document flows through a highly complex CM model that only you and a handful of process geeks understand to ensure that your project doesn't suffer from scope creep.
Traditional change management processes usually involve a group of people—a change control board (CCB)—mysteriously lead in most cases by the Manager of the project. This group will spend considerable time (and money) to decide whether your change will pass through the saintly process of an allowed change. These processes typically take days and in many companies weeks to process a potential change.
So before you enter into requirements management, or change management give consideration on what you are writing and why, also what you are trying to prevent and why. Do you really care as a PM if your stakeholders ask for change, do you really need to enforce your judgement on the situation?
Friday, February 23, 2007
Welcome to the Blogosphere
I hope to meet and blog with the many project managers out there who are changing from traditional Project Management to Agile.
One major issue I am trying to work through
1) Accounting for overall design on large scale systems- how would you go about this? There really is no code delivered so in turn no velocity.
One major issue I am trying to work through
1) Accounting for overall design on large scale systems- how would you go about this? There really is no code delivered so in turn no velocity.
Subscribe to:
Posts (Atom)
