Google CEO says everybody needs a coach

 

One thing people are never good at, is seeing how others see them. Ine explained this some time ago with some more words (dutch blog post)

Yep. As I am coaching both team’s and individuals I agree.
Do I have a coach? Yes I have had several coaches the last years. At this moment I have one that coaches me on a weekly basis.  And I know coaches that I can reach out if I need to. (Which I do from time to time when I look for specific advise.)

Do you have a coach?

I am Yves Hanoulle, your virtual Project coach and you can mail me: blog at my training company  .net

 

Agile conferences

To my big surprise I have not been blogging about the upcoming Agile conferences.

Agile2009_WebBadges_Self I’ll be going to Agile 2009 in Chicago. This is the agile conference to be.
Neatly organized by different stages like festivals.

Unfortunately this year non of my sessions got accepted; Oh well leave’s me more time to follow other sessions and network.

If you are going to this one, orif you have been to any of the earlier ones and you are on linkedin, feel free to join the Linkedin Agile 200X group.

 

agileee_banner_speaker_205x130 Next to that I’ll be speaking at the first Agile East European Conference in Kiev.
I love helping out new agile conferences. I spoke at the very first XPday France (in 2006) and I haven’t missed one since.

 

 

 

I have also proposed a few session on XPDay Benelux. I will do also for Xp Day London and I’m considering a lot of the Agile Tours cities.

Am actually also thinking about the Agile Testing days that are taking place in Germany and Belgium, Agile Open Holland, Agiles 2009. If you know of other agile conferences feel free to contact me.

Oh and this year I have created an agile conferences calendar on google. E-mail me if you want to add it to your calendars, so that you won’t miss any agile conference.

 

I  am Yves Hanoulle, your virtual Project coach and you can mail me: blog at my training company  .net

Fix price project in trouble…

Yesterday I receive this e-mail:

Dear friends,

Sorry to bother you, but I’m asking for your advice on the following
matter.  My company is engaged in a project that is losing money.
It’s a fixed-scope, fixed-money and we’ve badly underestimated the
effort required.  For the record, we started in May last year, and we
estimated it would be over in a year.  My current estimate for
completion is around March-June 2010, depending on how many people we
leave on the team.  Currently we are staffing 6 people, but the
original plan called for 4 people.

Yet the customer insists on paying us the fixed amount, and we’re
losing money badly.  The people on the team is discouraged; there is
no end in sight.  Our customer’s customer is also angry because of the
delays.  The only good thing is that we managed to keep the developers
working regular hours.

On Monday I’m going to have a Difficult Conversation with the
customer.  I’m going to ask them to convert the current fixed-scope
project into a variable-scope one.  I will tell them:

“Dear customer, the amount of money that you are still to give to us,
according to the plan, will allow us to keep this team going for about
15 weeks, working barely above cost.  We’ll do everything you need on
this project, for this time, so that we reach most of your major
business objectives.  After those 15 weeks, we’re even, and any
remaining scope will have to be done with a new contract, or possibly
with a new supplier.”

I’m going to list the following advantages:

* No more bickering about change requests; we’ll do everything you
need, in priority order.
* We’ll start splitting stories aggressively so that we can get the
most important functionality working, cherry-picking it from the whole
remaining scope.
* Working in a more focused way we can probably obtain most of the
business value you expected, since 15 weeks is a lot of time.
* Therefore, we’ll give you the maximum possible value for the money
that you originally intended to spend.

They are not going to like this; they are very much of the mind that
“it was your estimation error, so you must pay for your errors.”  My
view is that we’re working full time, with competent people, dedicated
full time to the project, so if we’re taking so long it’s mostly
because the project is complex.  It’s their product we’re building
after all; when all is said and done, they will have a product, and
we’ll only have the loss.

What I’m not comfortable with is, what to do if they refuse to see it
this way.  I’m thinking along the lines of,

“I’m sorry; if you refuse to cooperate, and bind us to this contract,
we’ll stick to the letter of the contract.  We’ll keep no more than 4
people on the project, we’ll take as much time as it takes, we’ll pay
our penalties and not worry anymore about your deadlines.  Also, we’ll
start doing things strictly according to the spec, and we’ll refuse to
do anything that is not in the spec.  If what we build is not what
your customer needs, then we’re sorry but it’s not our problem.”

I’m not comfortable with that, because it will be hell for the
developers, and it will possibly lead to the customer dumping us and
not pay us anyway.  And I don’t like to threaten anyone.  This course
will probably lead to great losses for both parties.

The other option would be to threaten to walk away from the project
right now; this would also lead to litigation and great losses for
both parties.  My boss does not approve of this possibility.

So I’m asking; what would you do in my place?  What would you say
when/if the customer refuses to agree to put a cap on our losses and
accept a variable scope project?

Thanks,

 

My scariest idea :

– Ask for help from the customer.

My less scary idea:

I guess that this team got into this trouble because they have created and delivered functionality that was not initially agreed upon. That in itself is normal. It is actually good to give the customer what he wants. I’s my guess that the problem in this situation is that the team did not remove other functionality. So now they deliver new stuff and the originally requested functionality. And then they go over budget.

So I advised this person to get a list of things they have added based on customer demand.

With that list they could now negotiate:

1 The customer pays extra for these extra features
2 Remove other initially features that are not yet developed.
3 Remove the extra features (not interesting for both parties)

These idea’s about fixed time and budget agile projects are based on two articles from Pascal Van Cauwenberghe. If you do fix price projecs, make sure you read these:

http://www.nayima.be/html/fixedpriceprojects.pdf
http://www.nayima.be/html/agilefixedprice.pdf

That are my idea’s. As this is a very tricky situation and I’m pretty sure some of my readers are smarter then me, feel free to e-mail me or post a comment with your idea’s.

I  am Yves Hanoulle, your virtual Project coach and you can mail me: blog at my training company  .net