On ineffective project managers

Probably it is time to rethink our project management strategy.

“Earlier Project Managers of our organizations have applied project management concepts so poorly that we need to switch to some other project management practice.”

“Perhaps the principles offered by PMI are not for the project managers of our organization. Why can’t we alter the project management methodology so that we can pacify our project managers?”

There’s a problem with the above thinking.

The incompetence of people in project management is never a good reason to alter the known, proven set of practices based on project management principles.

However better project management methodology poor project managers employ, they produce poor results.

Principles of project management methodologies are valued only when they’re used by the right people to produce the right results.

It’s never like those principles have worked for this set of people so it will work for other sets of people as well.

It is important to know what to change, why to change and when to change. It’s more effective when preceded by “whom” to change.

Random thoughts on software development

What should our software application offer?

How can we provide that amazing experience to our customers?

It’s about creating that awesome user experience.

Actually, It’s about creating value, isn’t it?

Oh.. and ROI too.

Need to do something that we haven’t offered, let’s make an iPhone app!

What do customers want?

…but, do they know?

…perhaps not, did anybody know how would an iPhone work?

Why outperform the competition, can we NOT make it irrelevant?

How about offering huge discounts this summer? It should work.

What about attending that trade show?

Let’s serve better coffee to our employees, they will love to work more.

…but actually, it was about doing less, more powerfully isn’t it?

Yes, it was but will try it next year maybe.

Shall I submit our software application for that award? Shall we make it?

Too much hard work is responsible for this crappy feature.

Let’s build a limited, great software application. Well, it’s good to have a few more features developed faster. Seems I miss the point.

Oh Gosh…Customers would have accepted our software if we haven’t offered those features. Let’s try once more.

Mini Saga – Key Discriminator

Answers like below may become key discriminator at the time of interview. However, it depends on the type of organization you’re having an interview with:

Key Discriminator

Kate appeared for a software project manager interview.

Interviewer: “Tell me about one thing you are NOT very good at?”

Kate:  “Software Programming! – That’s the reason I could focus on getting it done from other most brilliant colleague!”

This answer became the key discriminator and easier for the interviewer.

Your perception and the answers that follow your perception makes all the difference!

Lean software development

Approach #1: Offer many solutions. Get a mile wide but an inch deep. Provide tons of features that may (or may not) work, look forward to adding more.

Approach #2: Offer ONE solution. Get an inch wide but a mile deep. Provide only a few features that will always work, look forward to making those features better. Feel the fear but eliminate a feature that doesn’t work well.

The problem most product development organizations run into is that they trick them. Even if they think approach #2 is right for them, fear of losing a client by not offering certain features lets them enter the realm of mediocrity.

Or if they think that approach #1 is correct for them, they are touched by a recent lean software development conference they attended last week and want to eliminate the waste by trying lean techniques.

Lean Software Development is less about the right techniques and more about having the right mindset.

Building a product using approach #2 sounds cool but requires a fundamental change in thinking – now that’s a cost, choose Lean Software Development only if you are ready to pay that cost.

Winning a tough battle requires sacrifices, so does building a great software product.

Smart Vs. Trustworthy

She was managing one of the most important projects of the company for the past 2 years.

One day, the junior most team member asked her if he was smart, she said, “No”. He asked him again if he thinks that he wanted to have him in her team, she said “No”. Then he asked him if there’ll be any loss to the team if he stops coming to the work, she said “No”. He thought he had heard enough and wanted to resign.

As he went back to his desk to prepare his resignation letter, she asked him to stay. She said, “You’re not smart, but you’re TRUSTWORTHY, I don’t want to have you in my team, I NEED to have you in my team. And there wouldn’t be any loss to the team if you move on, there would be NO TEAM.”

Some team members are indispensable. They are the ones who make the team. If there are no such players, there is no team.

Trustworthiness is a superior trait than smartness so is doing remarkable work. It makes you indispensable.

On confrontation

Was that confrontation essential?

That’s the question you need to ask post each confrontation.

Sure, confrontation is a powerful tool in bringing your team members to the next level but pausing and measuring the progress is even more important.

Confrontation is more of a cost v/s benefits issue so the measurement is required. And, the thing about progress is that the progress will be always positive if you let it.

The key here is to look dispassionately at the whole set of confrontation events and take corrective actions whatever those might be.

What’s the point of continuing an activity if there are no benefits?