Avoiding Frustration

The other day I had a chat with one of my friends. He told me one thing.

There’s nothing more demotivating than being helpless. You only frustrate yourself.

We were talking about taking responsibility for a part of the company as a chance to deal with issues which annoyed us. We considered that as a chance to do something about that instead of ranting about the situation. But there is another perspective.

It doesn’t matter if you’re manager or tester – there will be thing which you don’t like and you don’t want to accept them in the long run. It can be atmosphere of the workplace, it can be lack of order in project management, it can be constant context switching, it can be beef-head boss, it can be anything.

Now, you either see you’re able to change the annoying issue or you end up as frustrated employee and eventually leave. Yes, usually managers have more tools to change the environment they work in, but the rule is general. If a developer can’t go through with his great ideas how to improve development his frustration will rise. If a project manager is struggling to move her projects a bit from the complete chaos with no effects she won’t be happy with her job.

If you’re a manager you have to give your people chances to change their workplace. The place they work in and the way they work. It doesn’t automatically mean you have to agree with each idea, but if you listen you’ll hear a lot of reasonable ones. Except of improving performance of your team you’ll also limit their frustrations.

Usability Issues: Responsiveness

You take this new app which is told to be better than the one you use at the moment. If you’re lucky it’s intuitive and you don’t have any problems to set it up. Then you start working. And it hits you. Important operations are slow. Not dramatically slow, but significantly slower than with the old app.

Take new shiny Vista box with new shiny Office 2007 and sometimes it’ll freeze for a second. Annoying. Your good old XP with Office 2003 didn’t perform like that. Take Google Spreadsheet try to cut and paste a piece of cells. What the heck is happening? Am I faster than the app? Oh, yes I am. It wouldn’t happen with good old Excel.

The clue here is responsiveness. How fast application will answer to most often executed operations. Lightning fast? Maybe as fast as industry standard? Or you’re just too slow?

This is the big issue especially for web applications. Responsiveness of the web is significantly worse than desktop application. As far as we used WWW just to browse websites it was natural since it wasn’t a replacement for an existing application but a completely new one. With financial, CRM, project management or office apps we’re trying to replace desktop software we use every day. If they’re slower the user experience descriptions will definitely use the word “frustration.”

Focus on your software responsiveness, especially on the most important functionalities. Compare to other, legacy software in your market. If you’re significantly slower, well, that’s a sign you have a task to do: improve.

Whole usability issues series.

Usability Issues Series

I was writing here about usability of applications on a couple of occasions. And since usability is made of small things I thought it’s a great idea to run another series of short posts on the subject.

There will be post per week published unless I’m off on vacations or some disaster happens.

Usability issues so far:

Responsiveness
Most frequent used means most important
Nice enough
Tab order
Quick start
Like good old app
Clean design

Functional Specifications: Obsolete or Not?

There are at least two answers to the question whether functional specifications are useful or not. Agilists would say specifications value is low since software will be changing significantly during iterations. The other party doesn’t even start a project without singed detailed functional specification.

I think both sides are right. Sometimes. It depends on client you work with. If you have a good partner to employ agile approach and you value this technique, go for it. As far as you are able to find a consensus with your client you won’t need detailed specification up front. Probably some documentations at the end of the process will be enough.

On the other hand there are customers out there who will exploit lack of defined functionality range to switch into feature creep mode. There will be a lot of new critical functions created on the fly. There will be a lot of interpretations how different things should work. Your only shield is anything which was formally agreed before. Possibly functional specification signed along with the agreement.

Actually it’s neither the size nor the type of the project which plays the main role here. Not even your software development and project management methodologies. The client is important. Let’s take a typical implementation for mobile operator (things I deal with every day). Project timeframe between 6 and 12 months. With the same system, similar scale and two different customers we need two approaches.

One client sets us a list of goals and work actively with us during development. We don’t even try to create detailed description of developed features and we expect a number of changes when they see first result of our work. Since client attitude is reasonable and they don’t bring things completely out of agreed scope it works fine.

Another client brings very strict verification phase when a number of new “improvement ideas” are submitted as bugs. As far as we don’t have detailed scope of work there will be some interpretations how different features should work. And since the requirements are changing over time (which is fairly natural) no specification means feature creep. A feature creep invited on the very late stage of the project which blows the schedule up.

Since I could say which style I prefer it doesn’t really matter. What matters is which style is preferred by our beloved clients. We can adjust ourselves. But the answer to the question from the title will remain the same: it depends.

Alternative Cost

You could have heard that several times.

How much time it will take to complete that?

Two months. But we can’t complete that project in two months from now.

Why? Isn’t that just a matter of resources?

No it’s not. Whole core team is at the moment fully engaged in other project and we’d need at least two of them here.

Let’s take two of them then.

OK, but consider the other project as late by half of the year. Fair enough?

No. Can’t you find other people to do job?

Yes I can. I will have them in the office in 2-3 moths. And after another half of the year they’ll be ready to undertake the task...

Resources (what a “great” name for people) are almost never time independent. When you talk about a team, they probably have work planned for next several months. Sure, you can go, change their priorities but you should always consider alternative cost of doing that.

It’s not only people’s work which costs you money. There are other commitments also. Commitments your salespeople have already cashed in their income forecasts. Commitments you’d have to break if you took some people out to other tasks. With all consequences. Consider those broken commitments as your additional cost. Alternative cost of focusing on something else.

Now you have the full picture. And full cost of telling the customer it’ll be done in a couple of months.

By the way: you’re really lucky if your salespeople understand this concept. Personally I’m lucky enough to work with really reasonable sales team. They do understand.

Fighting with Lack of Time

My last posts are mostly about dealing with workload. The reason is simple – last weeks at work are pretty hectic. Sleeping for 4 hours isn’t something very unusual these days.

Today I have another self-management tip. Leave less important things aside. If you lack time you should spend it neither on task switching nor on unimportant errands. That’s pretty obvious. Unfortunately we tend to forget about that.

And there’s another trap. We usually set unimportance level way too far. As a result we don’t have enough time to deal even with “important” tasks. The direction should be opposite. Start with the critical things and until they’re finished don’t touch anything else.

The rest should be delegated or forgotten.

Unfortunately for me it does mean significantly lower posting frequency on the blog, which I believe you’ve noticed. I hope to be back on track in a couple of weeks.

Don’t Be Afraid Of Small

At the moment we’re about 35 people here in Wind Mobile. We’re still considered as a small company. And sometimes clients still considers that as an issue.

Yes, I know, I shouldn’t be surprised, yet I am. At least partially. While I understand relatively small size of the vendor company brings some risks for the client it also brings a list of advantages which are usually underestimated.

Flexibility

Small is flexible by nature. If you’re small you much easier adjust yourself to environment. To ever-changing requirements. You’re much quicker when it comes to react for new situation. One of main big players on our market is known they never deliver any ordered change request in time shorter than a couple of months. Even if it takes them a manday. We are on the other end of the scale.

Cooperation

When you’re small you value relations. Since you don’t have loads of salespeople you sell via references. And you don’t have references unless your clients are happy with cooperation with you. Therefore you put much effort to improve the cooperation. Maintenance people like you. Product managers like you. It’s a win-win.

Engagement

Since each similar deal is relatively more important for small company than for a big one small organizations usually care more. If you don’t have comfort to be able to trash a project with almost no negative consequences for the company your level of motivation will be way higher. You’ll just care more.

And yes, choosing a small company is a kind of risk but most of the time it’s a worthy play. I don’t say that just support my ego. I’ve seen much more failure projects delivered by big players just because the vendor failed in one of above criteria (usually in all of them).

Of course you can always bring the old motto “No one got fired for choosing IBM” but at least don’t try to state you choose the best option.

Talk, but Listen

I guess you were in a situation where you knew everything about a problem. What happened (that easy since you see what happened). Why it happened (there they come, first simplifications). Who is responsible (I got you, Mister Guilty).

Then you have several options.

• Wait actively until the problem will resolve itself. In other words do nothing. That’s what most managers do. That way you avoid difficult discussion and all the hassle.

• Yell over them. Get people who are responsible for the problem. Tell them where they were wrong. Tell them what they need to change. Get them back to work as soon as possible. You know better.

• Talk and listen. Tell how you see the situation. Ask people who you believe are the source of the problem what they think about situation. Ask where you can be wrong in your judgment. Try to find the way to avoid this kind of problems in future. Jointly.

I always tried to avoid running someone down. But even in situations when I came to the point I was ready to choose that option open discussion with mind set to listen not to yell brought much better results. Like recently when instead of one issue I was sure we had we found two others, completely different problems.