Failure means distrust. Distrust to you about delivering on your promises; distrust in your ability to make a difference; distrust in you taking care. Basically, it is as simple as:

1. Drawing attention to a problem without communication of causes and planned corrective actions.
2. Repeating the same error again (when you do not change anything after step 1).
3. Making problem a habit, when it happens for the 3rd time. Now it is clear for everyone that you do not give a heck about what's going on.

After step 3 there is almost no way to recover.

At the resort I stayed with my family for a vacation, we had breakfast served at 8:00 am. The first time a crowd of about hundred people had to wait for extra 10 minutes till they started serving, I remember my thought "Can happen. Probably, they wanted to please us with something special and underestimated the time."

Waiting in the crowd the next day I thought "Something went terribly wrong here. There must be a serious challenge involved at serving at 8 am."

After the third time nothing could make me come to breakfast at 8 am. I knew they did not care that we all had to wait for 10 extra minutes in a crowded room. I had to find a solution for myself and I did! Thereafter we came to breakfast 10 minutes late. In other situations, when your customers have more flexibility, they will simply quit your service. They will not do that because  there are issues, but because you do not care.

Take care to fix issues your customers face.

Toy Story 3. Release date: June 18, 2010. 323 days from now. Does not that amaze you? No? Most likely you are not a Project Manager. And certainly not a software Project Manager.

In software world we know how hard estimation is. And to date I have not met a Project Manager, who would commit to a delivery date a year from today. Well. one can commit, but what about keeping this commitment. Recently Boeing postponed first flight test for its Boeing 787 Dreamliner till early fall. This might not sound bad, but what if originally this aircraft was scheduled to take off in 2007?

Surprisingly, in entertainment industry they know how to give promises and keep commitments (at the very least with release dates). How do they do that? I do not know for sure, but my take is that the "secret sauce" should be in very effective scope management. And, of course, expectations management.

When film is announced not more than title, broad story topic, and, probably, some of cast is told out. More details are given out to feed public's interest, but I bet they never tell us about something that can not be done by release date with high degree of confidence.

There is certainly something to learn from this approach.

Here are some links to interesting stuff on software estimation and projects planning for weekend reading and watching.

• Your Will Suffer From Power Laws. There are some things, which are the way the are, and you can not change them, even if you want. You can not spit upwind (at least, not with desirable result); you can not make an apple fall up, when you release it. So with our projects there are some things, which we simply have to learn to live with.
• 10 Deadly Sins of Software Estimation webinar by Steve McConnell. Interesting presentation about art and science of software estimation. A lot of references to statistical studies, which give good food for thought.
• Software estimation considered harmful? Alternative point of view on software estimation as presented by Steve McConnell. DeMarco and Lister refer to study, which suggest highest productivity on projects, which were not estimated at all. Does this mean we should not estimate our projects?
• Evidence Based Scheduling. Practical approach to software estimation developed at Fog Creek.
• Agile Management for Software Engineering: Dealing with Uncertainty. A chapter from great book by David Anderson. Something always goes wrong. The problem is that we do not know what and when, yet we have to plan and execute our projects. This chapter of David's book can help you.

Finally, a tip from Leo Babauta of ZenHabits to a project manager, who needs clear mind, when  project is derailed, for finding peace of mind.

I love the definition of solution from old good MSF 3.0:

Solution is the coordinated delivery of the elements needed (such as technologies, documentation, training, and support) to successfully respond to a unique customer’s business problem.

There several things in this definition that appeal to me:

• It clearly separates solution, developed with specific customer in mind, from product targeted at market, as also outlined in MSF Process Model.
• Customer's business is in the center of attention. And if the best way to address this problem is not development  of new software, so be it - it can be as simple as re-engineering existing system and providing adequate documentation or training; or instead of throwing development effort at scaling problem, one can just add more hardware capacity. Again, in case this is the best approach.
• There is no place for technology bells and whistles. If a mere VBScript can solve the issue, why waste precious time and resources on ultra-modern super-cool JavaFX (no offense here) development, if it does not add anything valuable for business?
• At last, technology is not a sole focus of solution development: delivery, documentation, training, etc. are equally as important.

Be sure to deliver your customers solutions and not just software pieces. "Software installed" is not a goal here, "problem solved" is.

[caption id="" align="alignright" width="180" caption="New roof at Wimbledon"][/caption] For years I've been using Wimbledon tournament as an example of really good uncertainty management: with all those games taking very different amounts of time, unpredictable rains (in 2008 man's final was interrupted twice) - it is a scheduling nightmare. Yet, man's final always happens on the 2nd Sunday of tournament (except for 2001 when it was raining on Sunday and final was delayed till Monday).

Wimbledon is scheduled for 13 days, beginning on a Monday and ending on a Sunday with the middle Sunday a designated rest day. The five main events span both weeks, but the youth and invitational events are held mainly during the second week. Traditionally, there is no play on the "Middle Sunday", which is considered a rest day. However, rain has forced play on the Middle Sunday three times in the Championship's history: in 1991, 1997, and 2004. On each of these occasions, Wimbledon has staged a "People's Sunday", with unreserved seating and readily available, inexpensive tickets, allowing those with more limited means to sit on the show courts. Additionally, if the tournament is not completed by the end of the second Sunday, all remaining matches are postponed until "People's Monday".

Wimbledon on Wikipedia

Tight rules, uncertain conditions - great execution!

Now the problem with rains is fixed at its roots: roof at Wimbledon's Centre Court. This does not fix the problem complete, as other courts are still under open skies, but weather area on Wimbledon's home page gradually becomes less relevant.

If you are a manager, you've got everything to prevent this sign from ever appearing near the entrance to you department's area.

Today I had an inspiring chat with one of fellow QA engineers about one of the systems we recently developed. I had a new requirement in mind that triggers complete re-test of the system.

Me: How long does it take to re-test our solution?

QA: Any new features or components?

Me: No, "just" another communication protocol.

[caption id="" align="alignright" width="180" caption="Great job!"][/caption]

QA: Give me 10 minutes, I'll consult with the Test Plan and Design.

Me: ...Ok.

And if initially I was going for really quick and dirty estimate, I just could not make myself ask for that. I've got my needs under complete control of a professional.

Professionals feel responsible for everything they say to you, their internal code of conduct just does not allow them to fool you or compromise quality of their advice, even if you ask for it.

Professionals, unlike amateurs, will always ask you for what they need to deliver you the best possible result.

They are near you, just look around.

Be reasonable with your requests. Be reasonable with your responses. Human actions (at least, in professional and business fields) are mostly driven by reasons. People never (or very-very rarely) do something out of spontaneous wish at work.

Yes, you can have a spontaneous idea, but it, anyway, will serve some particular purpose. Idea tries to solve a problem, and the is the reason why you do that - you want right the wrong or make something better.

Often times in order to do what you want to accomplish, you will need to request something from your fellow colleague. Usually, you will need to have it done by certain deadline. This is where the interesting part begins.

You know exactly why you want something to be done by certain date or time. But are you sure your fellow colleague, from whom you request, comes to know that by reading your e-mail? Does he get why this needs to be done today? Is it in any way more important than what he is working on now? Unless he is a powerful mind-reader the answer to all such questions is "No!". E-mail just does not bear with itself enough of  the mental energy to discover all of that!

Do you want you request to be handled in the best possible way? I bet you do. So, be reasonable. Write you request in a best possible way. Explain why there is a need to do something and why deadline is such as it is. Do not send unreasonable requests!

Same line of thought applies to responses. And even if you receive an unreasonable request - there is a reason why it went out. Help the requestor. Ask him questions. Unreasonable response will just turn into a dead-end. Often quickly bricked up behind your back while you drive there.

Do your best to explain your reasons and understand reasons of others. If you are not sure if you were understood correctly - follow-up your e-mail with a call.

And be reasonable with what you write and what you say.

When people communicate they exchange facts, ideas and opinions. When they hear something which is not a sure fact like "At present, Earth orbits the Sun" they will either agree or disagree. As Paul Graham suggests this is a natural behavior. But disagreeing itself is somewhat simple: nothing remains after the conversation except for changed or not unchanged mind of participants.

[caption id="" align="alignright" width="180" caption="Opposition"][/caption]

When people hear idea or proposal it is another beast. Something is going to remain after the talk is finished and that is a decision whether to proceed with presented idea. And that decision, be it positive or negative, is going to affect everyone involved in a conversation. As Paul noticed

Many who respond to something disagree with it. That's to be expected. Agreeing tends to motivate people less than disagreeing. And when you agree there's less to say.

Only very bad ideas will not ignite discussion. If the idea is worth at least something the conversation will start. The conversation will start with disagreement and critique and will revolve around the problem idea tries to address and the idea itself.

The worst form of critique which often can be a "discussion killer" is when the reply is "This is not going to work" and nothing more. There can be several cases why one would say that and actual meaning of that response can range:

• from "Hey man! You are so stupid to propose this. Your idea is not even worth discussing."
• to "Dude, I had thought this idea in and out and you really do not want to implement it" and "The problem you are trying to solve isn't really a problem. Let's move on to the next item."

No matter what the actual meaning is expressing it with "This is not going to work" is wrong. You must uncover reasoning for "not going to work". Such unsound responses kill all the constructive outputs that can arise as a result of conversation on the topic. Such responses create forces which oppose to development of better outcomes for the concern raised.

Good response would be something that will help arrive at conclusion that will be both acceptable and accepted by all the parties engaged in the conversation. Something that will prompt for further discussion is already good enough, e.g. "I do not clearly see the benefit of implementing this. Can you please explain in more detail?".

When discussion starts it is important to distinguish two things about the proposed idea:

• problem the proposal tries to address
• the idea itself

First of all there should be an agreement on why dealing with the problem is or is not important. With readiness to attack the problem you can move on to define a solution to that starting with proposed idea. Once the problem is revealed a solution should be found. The solution might be completely different from what is proposed now, but there should be one. And only constructive dialog that gradually improves currently proposed idea can deliver that.

Jim McCarthy calls this a "better idea" approach. To quote Jim:

An accountable "No" is respected, but it's got to be accountable.

You can say "No", but no, you can't go away without a better idea. Because if you don't have a better idea, then that's the best available idea and you always act on the best available idea. You can always change it tomorrow, or next week if better ideas come around. But, by definition, if you don't have a better idea, you have to vote "Yes". So when you stop the show you are expected to carry the next vote, which happens immediately. And this makes people say "No" much less.

Mind how you respond to ideas of your fellows and be accountable for what you say. Let ideas emerge and be implemented.

All of that started with Twitter... I created an account on Twitter. My way to Twitter was quite long and there were, I guess, 3 major factors that made me do that: changes in my professional life, Bob Walsh's comments about Twitter and Hanselminutes episode about WPF Twitter client blu. In my 2 or 3 days Twitter "career" I've already seen famous "Something is technically wrong" so I can see myself as an experienced Twitter user.

But there are 2 other things that prompted me to think about software quality.

After listening to Scott Hanselman's podcast I installed blu. The second thing I noticed after slick UI was inability to work through proxy. I live and die by personal proxy which allows me to easily migrate between different networks during my day. So, what can I say? Nice piece of software, but almost completely unusable in my setting, which as I would guess is not uncommon.

Another sad experience is twitbacks. As a newbie I given in to temptation of working on form rather than the meaning first. I've spent quite a time with this tool, but was not able to produce any sufficiently good looking background. Main issue for me was strange resizing which made text blurry and also lead to incorrect alignment with functional elements of the Twitter page. Again, nice idea, but not usable.

Both of these cases look to me as an obvious shortcuts taken by the development teams on requirements definition or testing stage. Quality of the system output is determined by weakest link in the system. Determined to the extent that piece of software may be rendered unusable in certain common scenarios.

Network client solution cannot omit widely spread variances in Internet connectivity settings.

Image generation software can not afford generating funky images.

Check that you have not fallen into the same trap or start fixing that immediately.