Customer Service

Picture worth a thousand words.

Optimism Bias

Optimism bias is the demonstrated systematic tendency for appraisers to be over-optimistic about key project parameters. It must be accounted for explicitly in all appraisals, and can arise in relation to:

• Capital costs
• Works duration
• Operating costs
• Under delivery of benefits

To minimize the level of optimism bias in appraisal, best practice suggests that the following actions should be taken:

• Project managers, suitably competent and experienced for the role, should be identified
• Project sponsor roles should be clearly defined
• Recognised project management structures should be in place
• Performance management systems should be set up

For large or complex projects:

• Simpler alternatives should be developed wherever possible
• Consideration should be given to breaking down large, ambitious projects into smaller ones with more easily defined and achievable goals
• Knowledge transfer processes should be set up, so that changes in individual personnel do not disrupt the smooth implementation of a project

AOF

Risk Management

Project Estimates

A common problem I have in a corporate environment is to accurately portray an estimate. We are estimating time and cost for software projects. The key issue is that software development estimates are highly inaccurate in the early stages, with errors of 200-400% quite common and a high degree of positive skew is evident. Overruns are more common than under runs and extreme overruns are alarmingly common.

The main problem is to express the uncertainty as clearly as the expectation, without appearing too elaborate.

In the past, we might say "There is a 90% chance that it will take 1-2 years and cost 5-15 million dollars". This magically turns into "You said it would take 1 year and cost $5m!".

We are dealing here with people who have zero statistical sophistication. There is a confounding factor that people want low numbers so their project gets approved over others.

I have some ideas:

1. Plot time or cost by probability.
2. Plot time by cost as a probability density cloud.
3. Express estimates like this (wide range, round numbers)
"
More than $3m
Less than $30m
"

Tim

P.S. I feel someone will suggest "Do better estimates then you won't have a problem". The fact is, until you have dug into the technical uncertainties and have defined requirements in detail you are subject to major technical risk and scope screep risk. You also have a serious problem of framing - the number the customer first thought of is likely to be way under the mark.

-- Tim Josling (email), May 15, 2003

Find about more on this
http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0000Vz

How NOT to Plan a Project

5 Steps to project success!!

The Myth of Software Estimation

A few months ago a web service I’d written began to eat up memory like crazy. I’d coded it using a modern garbage controlled language so theoretically a memory leak was impossible. But, it was happening. I tracked down every obvious choice. I talked to my co-workers. No luck. Finally, after two weeks I finally discovered the problem–a small bug inside a loop was interacting with Microsoft Active Directory to create hundreds of AD tokens. Another bug caused these tokens to skip garbage collection. Schedule? Throw that to the wind.

Evidence Based Scheduling

Using Evidence-Based Scheduling is pretty easy: it will take you a day or two at the beginning of every iteration to produce detailed estimates, and it’ll take a few seconds every day to record when you start working on a new task on a timesheet. The benefits, though, are huge: realistic schedules.

Realistic schedules are the key to creating good software. It forces you to do the best features first and allows you to make the right decisions about what to build. Which makes your product better, your boss happier, delights your customers, and—best of all—lets you go home at five o’clock.

Life of a BUG In Bugzilla

Wiki for Agile Development

Here's a summary of ways that wiki can help with agile development. Need to add illustrations of each of the components and reference links. Improvements and additions most welcome Adina

Wiki was invented to help with Extreme Programming, and can be very helpful in various phases of agile development process. For those not familar with the buzzwords, Agile is a family of development methods with shorter, more iterative cycles than traditional "big bang" development.

Wiki can be useful in a range of XP and agile development practices, including:

• Planning game -- co-operative planning of short iterations with the customer
• User stories -- plan development based on stories where the user achieves a goal
• Acceptance Testing -- user define the criteria for a successful feature, and tests are developed based on the user goal
• Standup meeting -- frequent short meetings to check status and troubleshoot
• Metrics for problem-solving -- monitor progress using a small carefully selected set of metrics designed for specific improvement goals

Wiki also helpful in facets of development not tied directly to XP

• Emergent documentation
• Product requirements roadmap

More >>

TDD = Refactoring + TFD.

Creating a Product Backlog

Very good thought about how the product backlog is created and prioritized. Nice diagram that helps a lot in the real world.

Agile modeling

The best practices of AMDD are:

1. Active Stakeholder Participation. Stakeholders should provide information in a timely manner, make decisions in a timely manner, and be as actively involved in the development process through the use of inclusive tools and techniques.
2. Architecture Envisioning. At the beginning of an agile project you will need to do some initial, high-level architectural modeling to identify a viable technical strategy for your solution.
3. Document Late. Write documentation as late as possible, avoiding speculative ideas that are likely to change in favor of stable information.
4. Executable Specifications. Specify requirements in the form of executable "customer tests", and your design as executable developer tests, instead of non-executable "static" documentation.
5. Iteration Modeling. At the beginning of each iteration you will do a bit of modeling as part of your iteration planning activities.
6. Just Barely Good Enough (JBGE) artifacts. A model or document needs to be sufficient for the situation at hand and no more.
7. Model a bit Ahead. Sometimes requirements that are nearing the top of your priority stack are fairly complex, motivating you to invest some effort to explore them before they're popped off the top of the work item stack so as to reduce overall risk.
8. Model Storming. Throughout an iteration you will model storm on a just-in-time (JIT) basis for a few minutes to explore the details behind a requirement or to think through a design issue.
9. Multiple Models. Each type of model has it's strengths and weaknesses. An effective developer will need a range of models in their intellectual toolkit enabling them to apply the right model in the most appropriate manner for the situation at hand.
10. Prioritized Requirements. Agile teams implement requirements in priority order, as defined by their stakeholders, so as to provide the greatest return on investment (ROI) possible.
11. Requirements Envisioning. At the beginning of an agile project you will need to invest some time to identify the scope of the project and to create the initial prioritized stack of requirements.
12. Single Source Information. Strive to capture information in one place and one place only.
13. Test-Driven Design (TDD). Write a single test, either at the requirements or design level, and then just enough code to fulfill that test. TDD is a JIT approach to detailed requirements specification and a confirmatory approach to testing.

First Day at New Company!!!

This is a wonderful day in my life. I mange to be on time at the office premises. Although many important people are missing today, others made this day quite a bit exiting and encouraging. Met with many people who are bit busy but made me understand how important the work ethics even when the senior members are not present.

I spent most of my time reading company policy manuals. Looking forward to get my hands on to projects in coming weeks.

Good Bye! ECode ...

Dear Friends,

The moment has arrived to say farewell, hoping that I have some more time till the ‘End Times’. Left with only the sweetest reminiscences to carry away and leaving my spirit that will forever say Thank you,

KIT

Team Building: Evolution Not Revolution

Play. Estimate. Plan www.planningpoker.com

Never start a project unless all resources are available

May be not all, but critical resources. It's Project Manager's responsibility to Level the resources through the project life!

Last Sermon at Ecode Lanka Software

I think the record should show that this is one of those spontaneous things that we always arrange whenever a loved one departs and it will be so reported in your hearts and I am proud of being one of them.

But on my part, believe me, it is spontaneous.

You are here to say goodbye to me, and I don't have a good word for it in English -- the best is au revoir. We'll see you again some where some how.

I just met with the members of the ECode, you know, those who serve here day in and day out, and I asked them to do what I ask all of you to do to the extent that you can and, of course, are requested to do so: to serve our next Project Manager as you have served me and previous Managers -- because many of you have been here for many years -- with devotion and dedication, because these great teams, great as it is, can only be as great as the men and women who work with rather than work for.

I wish to say some thing about ECode. This isn't the biggest. This isn't the finest. But this is the best. It is the best, because it has something far more important than numbers of people who serve, far more important than the facilities you get. Ecode is best only because of you. Ecode has a great heart, and that heart comes from you.

And so it is with you. I look around here, and I see so many on this staff that, you know, I want you to know that each and every one of you, is indispensable to this Office.

It is only a beginning, always. The young must know it; the old must know it. It must always sustain us, because the greatness comes not when things go always good for you, but the greatness comes and you are really tested, when you take some knocks, some disappointments, when sadness comes, because only if you have been in the deepest valley can you ever know how magnificent it is to be on the highest mountain.

And so I say to you on this occasion, as I leave, I leave proud of the people who have stood by us regardless of Happiness or Sad. I want you to be proud of what you have done and achieved.

<<>>

Always give your best, never get discouraged, never be petty; always remember, others may hate you, but those who hate you don't win unless you hate them, and then you destroy yourself.

And so, I leave with high hopes, in good spirit, and with deep humility, and with very much gratefulness in our hearts. I can only say to each and every one of you, we come from many faiths, we pray perhaps to different gods -- but really the same God in a sense -- but I want to say for each and every one of you, not only I will always remember you, not only I will always be grateful to you but always you will be in my heart and you will be in my prayers.


Thank you,

Specail Thanx to Ex US President Richard Nicson

Shaf Resigns... Who Next?

New Opportunity

I am appointed as PM at Teamwork Technologies.

After successful evaluation test and a screening process they appointed me as the Project Manager.

Nice to see blogs

Colin Bird's Blog

Scrum "A WAY OF LIFEcycle"

Being Happy

PMBOK ® Guide Fourth Edition Changes

Tips to avoid project chaos