Certainties & Serendipities

If obtaining feedback is essential, it is even more critical to avoid common traps associated with getting that feedback. Here are some of the common traps¹, I have encountered:

Composition of team

Since government functions based on rank and class, a meeting will inevitably have dead-weights. They have no intention of providing any useful feedback. They are there just because there were asked to. They are harmless. But there is a set of people who can derail any hope of having a meaningful discussions. They are the Pseudo-Experts¹. Not only most of their talk will be useless, they will hold you prisoner to their expertise. Handling them will require all the emotional and psychological strength that you can muster.

Hijacked objectives

Another trap is that a feedback meeting is pulled back into a brainstorming session. Members start to discuss ideas that were left out, or come up with new ideas where much time had already been spent to arrive at the current solution. Most often these hijacks are unintentional, but sometimes it’s done to subvert the project. Unintentional diversions can be graciously handled, while the later has to be handled diplomatically, only with the support of the client.

Delegation to lower level (non-decision-makers)

Those who are in-charge of providing feedback do this in the pretext of being ‘too-busy’. The lower level resources won’t have the authority to take any decisions draining your enthusiasm for the project rather quickly. You need to bring this to the notice of project sponsers as quickly as possible.

These are the top three traps I have witenessed. What are the traps you have witnessed?

Obtaining feedback is critical to designing products¹ that stand the test of time. But getting meaningful feedback isn’t easy. If it is tough in a corporate environment, it is even more difficult within Government setup².

So how can you get the best feedback?

Interestingly, most of the necessary activities happen outside the meeting room (I’m thankful to my earlier boss for demonstrating this to me time and again).

To start with, you need to know when to obtain feedback. Not too early, despite the pressure to send the ‘first draft’; not too late, despite your love for perfection. Appropriate time is when it is small enough to be manageable and big enough to be relevant. As your product evolves, you need to repeat this process until the final delivery. This iterative process also gives you an early sign of future problems. If you sense any problems to come, you could still do course correction.

You should engage the client team as often as possible – mostly informally – to get their ideas about the project as well as your creation. This enables you to get insider’s perspective of the project. Let us say you find out that the project is a low priority one, you can be sure that getting feedback will be of even lower priority.

If you could influence the composition of the group to provide feedback, you should do it by all means. There should be an ideological resonance within the team towards the project and hence to the product, without which feedback sessions will be disastrous.

Circulate the document well in advance giving the members ample time to read and come prepared. Some people would advice to keep the group in suspense but I don’t think it is a good idea. In my experience, circulating the document and engaging the members before the feedback meeting ensures better feedback during the actual meeting.

If you have executed the above steps diligently, feedback meeting should be effective. Still surprises can come from any corner. To wade through these surprises, you should designate someone as a facilitator in the meeting. The sole responsibility of the facilitator is to ensure feedback from every one is obtained and rants are controlled effectively.

At the beginning of the meeting, set specific goals for the meeting – feedback only on Table of Contents; feedback of only the process flows but not the mock-screen elements and so on. Give the participants a structure to think and provide feedback. Our ancestors have already proved that horses with blinders run faster and on track. It will be the duty of the facilitator to ensure that the blinders are on throughout the meeting.

Given to itself, meetings have a way of turning into chatter rooms. I have also witnessed feedback meetings morph into review meetings of other projects of the clients, because they want to take advantage of the presence of the members. Since it is your meeting, it is your responsibility to steer the meeting back into track. As situation may permit, go and stand in the front. If available utilize the board. That is a proven way to take control of the meeting (another point which was emphatically proven by Mahendra again and again).

An important activity that gets left out is the follow-up. Follow-up is not limited to sending the minutes; but also introspecting what went right and what went wrong, if possible with few of the client members. This is a great enabler for successive meetings turning into success.

Now it is your turn. Tell me – via twitter, email, gplus – what else do you do to get the best feedback that you deserve?

Image by: HikingArtist

The Internet is buzzing with Code Academy‘s code a year program. Everyone is signing up for it, even Mike Bloomberg, New York Mayor, signed up for it.

Is Code Academy trying to beat the universe?

Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. ~ Rick Cook

Oh! wait, you can’t do that with 200,000 people signing to code. That is like sending everyone in town with a camera hoping that someone will turn out to be Ansal Adams. It doesn’t work that way. Not in photography, not in coding, not in project management, not in anything. But we don’t learn our lessons, letting the universe win.

As Vijay Sankar, tweeted,

hmm..not too sure about this “everyone shud learn to code” movement…world does not need MORE coders, we need BETTER coders #justsayin

How I wish some psychology expert would explain the illusion of quantity magically producing quality.

Governments, corporates, and individuals are all obsessed with this illusion.

What to do when a project goes for a toss? Add people¹.
How do we prevent fraud? Add more controls².
I want to improve my writing. What should I do? Write 700 words every day³.

So the magical answer is ‘do more’. But, more of the same only produces more of the same results. Nothing improves. Wait, it is not same results; it gets worse.

As I have realized after managing many projects,

to plough a field, you need two strong oxen; not one hundreds chicken

More often than I care to remember, I’m given hundreds of chicken. The field smells only of chicken shit.

With plethora of PMP certified professionals and management graduates in IT industry, it is surprising that 40% of IT projects still fail.

Part of the problem is learning to make project plans only for happy-path scenarios. We don’t learn what factors could derail the project and what we can do about these factors. “We learn from our mistakes”, remains often repeated but quickly forgotten phrase. We can’t learn from mistakes because we, as humans in general, are averse dissecting them.

But Michael Krigsman, CEO of Asuret, Inc., is doing just that. He runs a blog, called IT Projects Failure, where he analyzes failures of various IT projects, majorly ERP as it is falls as a bigger pie of IT project implementation. Latest one being Marin County’s lawsuit against Deloitte Consulting and SAP.

He not only provides analysis of such failures but distills these learnings into early warning signs of failure and how to prevent doom among other lessons. He also bunks the myth that only large projects fail.

If you are a technology project manager, go read his blog posts. You will avoid repeating mistakes of many.