Users Like What They Know

You plan to introduce a new version of your widely spread application and one of key features will be new user interface. Or maybe you enter the market with new product which shall compete with market leaders and now you design GUI for your app.

And you have lots of ideas how to organize user interface better than it was done before. That’s for sure.

Unfortunately it does mean you set up a goal which is hard to achieve. I can even assume all your improvements ideas are great, which is rarely true. But let’s not complicate the situation. They are great.

You launch your new version/product/whatever and complaints start. We want to have spreadsheet working Excel-like. We want to work on Gantt charts in a way we work with MS Project. We want to have search looking like Google. We want to have invoicing window the same as it is in SAP. We want to have it the way it used to be. Keep your great ideas for others, we want our old damn interface back.

Because we like what we know. And we don’t want to learn new ways of doing things we do. We just don’t.

If you want to try to change the world of users habits you have two ways. You either believe your idea is strong enough to prevail or you stick to standards (no matter how low they are) and work hard to teach users new ways of doing things. The most obvious example of former is Google with clean search engine design. The examples of the latter can be Project-ON-Demand or Google Spreadsheet.

The first option has much higher failure rate. For each example of success you can find a bunch of examples of failure. From time to time I check different applications from area of project management and every time I see GUI totally different from what MS Project offers I see incoming failure. People won’t know it so they won’t like it. I don’t say MS Project is cool. It isn’t. I don’t like MS Project. Actually I hate it. But I used to it and most people around did too. Everyone knows how it works. Everyone expects other software doing the same things will work similarly.

Sure, you always can try to educate me with different approach but remember I’ll be reluctant. I’m like a typical user. Users like what they know. And they are lazy too. Remember about that next time when you start redoing all your user interface or reinventing the way people do things.

Clean Your Inbox

I was held at work today a bit longer today as we had a nice discussion about how our email inboxes are organized. Of course there are different strategies applicable in different roles but we had one common conclusion.

Clean your inbox.

Usually a number one reason for forgotten tasks is cluttered inbox. It doesn’t matter which techniques you use, just make it clean according to your standards. It will help.

By the way if we had our inboxes cleaned and there was no issue to talk about I would make my way out and wouldn’t be grabbed to an ad-hoc meeting. And that’s another argument supporting above thesis.

Promotions from Both Sides of the Barricade

I had quite an insightful discussion lately about promotions. When people hit the ceiling. Why it is so. What to do in that kind of situation.

Of course, as always, I won’t give you a sure-shot answer but from my observations a number of promotion issues have sources on both sides of the barricade.

Managers suck with promoting people.

Above generalization is built from small pieces including:
• Poor knowledge about people working in the team.
• Inability to take the risk.
• Virtually no information about how people are willing to build their career paths.
• Poor judgment.
• Lack of will to train or coach promoted people.
I don’t say every manager can be blamed for every of above points but probably almost every manager can be blamed for at least one or a couple of them. I’m no saint here if you ask me.

With all those problems managers often tend to choose outsiders instead of insiders as all those issues supports fear of failure. Then the most important thing kicks in. When you promote good specialist from your team to another position you actually lose specialist with no guarantee you gain suitable person on the new position. The fear skyrockets. The question pops: is promoting an insider really a good decision?

Most likely it is. Not allowing people to develop themselves you risk of losing them at all. You end up with no specialist on either position. And from my experience outsiders are much more risky than insiders. It’s much harder to judge a person after one or a couple of one-hour meetings than after a couple of years working in the team.

The fear is the most important issue on manager’s side. But it should be overcome.

People suck with promoting themselves.

How many times you hear a friend or colleague who is complaining how hard is to get promotion and you want to ask if her manager actually knows she want to be promoted? How many times you see people who don’t try to do anything with their career just waiting for bosses to do something about that? I can add a number of people who haven’t even tried to talk about what they like and what they don’t like about the job with their bosses. They just left rejecting a chance to change anything within their workplace. Even when the chance was just waiting for a smallest piece of initiative from them.

Sure, managers aren’t cool with promotions but most of them are in fear of losing good people. And sometimes they’re just lost with looking for a good candidate in the team and giving them some hints what you’d like to do can be really helpful for both sides.

Remember managers don’t know everything about their people’s professional goals. They should but they don’t. As far as you leave all in their hands you put your career in risk.

Don’t fear talking with bosses. You can’t lose much as far as your superior isn’t a kind of psycho. Help them. Put a pressure on them. Hey, that’s what they’re paid for. Managing their teams.

Among the best promotions I remember there’s a significant place for those which were made in difficult situations when both manager and employee overcame their fears, started talking with each other and found a way out. Profitable for both sides. And it all began with honest discussion about future with a boss.

Don’t Take It Personally

You go to a meeting with a client. You expect discussion won’t be easy so you work hard to prepare yourself. You know your team screwed something in the past but you want to look to the future. Anyways you expect talking about merits.

You get a bucket of crap dropped on your head on the very beginning. Then your failures are pointed and criticized. And then you hear people on the other side have no empathy to share your pains.

Sounds familiar? For many of you it should.

After those meetings I always feel like I was slapped into my face. I feel like someone has drained my whole energy. My motivation peaks down.

That’s utterly and completely wrong. You shouldn’t take it personally. Me either. You should care as far as it pushes you to improve things and that’s all. You shouldn’t allow those situations to influence your work negatively.

Why? Because it is business. They have to play “you screwed” card to show you they’re unhappy. Nine vendors out of ten would ignore them if they just said they were unhappy so they hit high tones since the beginning.

You’ll go to the very same people a couple of months later and they’ll be all happy with your efforts and performance improvements. They’ll remember neither a bucket of crap nor lack of empathy. The future will look bright.

Why? Because it is business.

You shouldn’t take it personally. Or at least you should try to act like that. I can’t guarantee you a success, as I’m rather a failed example here. Even though I know how it works.

Top 4 Post Mortem Issues

Some time ago I wrote about post mortem basics. As anything else in project management post mortem is not a silver bullet. There are a number of issues you’ll face when you do it. These are my top 4 listen in no particular order.

1. Get people involved. If you want to make a good post mortem you have to get people involved. On general people don’t want to be do that as that’s another additional task for them. No one likes additional tasks. And usually it has nothing to do with value of feedback they can provide. Sometimes I get worthy opinion from people who I have to force to receive anything from. Of course typical quality of post mortem answers will be better when someone do it because she wants, than when you force her to participate. But anyways the more opinions the better.

2. Compromise. You’ll get some points which are submitted to different categories by different people. You have to find a compromise there. Usually you need to understand reasons which stand behind an opinion. You can talk more with people who provide their feedback. And sometimes you’ll just know why someone thinks a quality engineer on client side sucked and someone else believes he was one of greatest thing which happened during projects. Maybe these are different ways to tell that client tests were very good but unfortunately solution’s quality sucked and that’s why customer tests were ordeal.

3. Discussion. You can prepare good starting point. You can encourage people to share their thoughts. And still discussion can fall flat on the face. And while answers can be forced somehow, you can’t force hot discussion to happen. Thing you can do is to focus on preparing better summary when you don’t expect a lot of ideas flying over the room while summarizing outcomes.

4. Improve the future. If you don’t plan to use post mortems to improve future projects don’t even bother. Don’t waste your time. Let the team do the work which brings you something valuable. Doing post mortems just for the sake of doing post mortems is just dumb.

10 Qualities of Good Project Manager

1. You should be a great organizer.

2. You should communicate more often.

3. You should be honest with clients.

4. You should look for solution instead of ones to blame.

5. You should like to work with customers.

6. You should understand business story laying behind the project.

7. You should understand technical issues which appears during implementation.

8. You shouldn’t hesitate whether to escalate or deliver negative feedback whenever needed.

9. You shouldn’t cry over unfair opinions about your work and your projects.

10. You should always expect unexpected.

Not Competent Enough

You’re a manager and someone calls you to tell about some emergency situation. The first thought is “I’ll do that.” I’ll replace sick guy who was in the middle of resolving the issue along with a subcontractor. I’ll run the meeting where all the technical issues are resolved.

Stop for a moment. Take a step back. Are you a person who’s competent enough?

Do you know all the history of communication with the subcontractor? Can you make good decisions how to deal with all technical stuff? When you’re a manager quite often answers will be negative.

Then the best thing you can do is to find someone who is competent. Playing a hero doesn’t pay. Sorry. Admitting you aren’t competent enough to deal with the specific issue doesn’t make you a poor performer. It makes you a wise performer.

Post Mortem Basics

What is it?

To make long story short post mortem is a little discussion after a project or important part of project. The team discusses what was done well and what was screwed. Before discussion one person gets feedback from all team members to bring a food for thought. Outcomes are used in future projects.

What’s in it for me?

Why to do post mortems? You usually feel what went wrong and what went well. But do all team members feel the same? Does a developer care if communication with a client went perfectly? Does a project manager understand all architecture flaws developers had to face? Does quality assurance team was aware about complex hardware installation part?

Post mortems bring two main outcomes.

1. Knowledge sharing. Everyone adds their two cents. All perspectives are included. Even the least important team member can bring a refreshing insight about project.

2. Written summary. The process of preparing post mortems forces a person to prepare a piece of document before discussion. You just raise your chances to have a written summary after all which won’t fade in a week.

How to do it?

The scenario is simple:

1. A person who knows a project well, ask all team members to answer three questions:
• What went well and should be repeated in future projects?
• What was on a good path and should be improved in future projects?
• What went wrong and should be avoided in future projects?

2. Then the person needs a lot of squeezing to get answers from most people from a project team, as many people won’t just answer a polite request.

3. All answers are assembled into one summary. That’s part can be tricky as it sometimes happen the same thing will be put in different categories by different people.

4. The whole thing is discussed and adjusted during team meeting, when everyone can add anything what comes to her mind.

5. Post mortem can be, and should be, used to improve future projects.

The questions can be adjusted if you feel like it, although I find the more general they are the more interesting things people will bring in answers. You don’t force people to change their perspectives, you just let them exploit their area of competence.

When to do it?

Definitely when a project is finished. But when you run a project which lasts three quarters you won’t remember all the issues you had to resolve during first phases after all. Then it’s quite a good idea to run post mortems after each important milestone.

When you shouldn’t bother?

If you don’t plan to use post mortem outcomes to improve future projects, don’t waste your time. Looking back is worthwhile only when it is a tool to improve future.

Prioritize That!

Whether you’re a project manager or a developer or a support engineer or you call it who you probably are asked quite often to estimate some work effort. You do your estimates, sometimes better sometimes worse and go with a number or better a couple of them. A person who was asking takes the number, if you gave two of them the higher one will be forgotten, and fades in shades of the office.

You forget the whole thing as it has never happened.

And then, after weeks of being processed by business processes, your estimate comes back to kick your ass.

“You said two weeks. I want to see that delivered in exactly 14 days from now. Bye.”

Hey, has anybody thought about other tasks I have to do? Or maybe I’m considered as a person who does virtually nothing, just waiting for a task to be assigned? That way I guess I should have been fired, shouldn’t I?

These are wrong answers. Don’t try that at work. But you can do what common sense tells you to do. Ask about priorities.

“Of course, that can be done in fortnight but other tasks will be dropped. If that one has the highest priority I’ll stop doing anything else and complete the new task as soon as possible.”

Ask for prioritizing the task. You’ll give yourself a chance to avoid being blamed for a slip. You’ll give better-informed people a chance to make a wise choice. You’ll make folks aware that resources aren’t made of gum and can’t be stretched as much as most of people think.

It works whether you manage just your own work time or you have a big team working concurrently on several projects.