Pawel Brodzinski on Software Project Management

Communication in (Not Only) Project Management

2008-10-06T22:02:00.006+02:00

Cornelius Fichtner left a comment under my post about waiting until others guess what we’re thinking. Cornelius says:

The lesson from this story translates extremely well into project management: You have to manage stakeholder expectations through proactive communication.

Actually, the situation when we and our customers look at the same thing very differently is nothing uncommon. That’s probably bread and butter of every project manager. Depending on methodology you use the answer will differ: you’ll go for detailed specification and formal requirement gathering process if you use one of heavy-weight methodologies or you’ll choose short iterations and frequent verifications by the customer if you’re agile. It doesn’t really matter.

The clue here is communication. It may happen very intensively on the beginning of the project and later you can refer to agreed specifications. It may be scattered with the same intensity over whole project. But whenever any detail is ambiguous we should communicate to get rid of ambiguity. Unfortunately we so often choose to make some (usually wrong) assumptions instead of communicate.

Now, forget about project management and think about life generally and the advice will be the same. It happens oh so often we’re angry because someone doesn’t guess what we’re thinking or we expect something is perfectly clear while it was stated in ambiguous way or wasn’t stated at all. Communicating instead of assuming is almost always a better choice.

Don’t Expect They’ll Guess

2008-10-04T23:56:00.000+02:00

One of hundreds of similar stories. This particular one from company my wife works for. A guy was underperforming. Bosses decided to cut his bonus money. He got frustrated and his engagement fell flat on the face. Bosses thought he didn’t care at all.

An easy situation, right? No. Pretend for a moment the sentence “a guy was underperforming” don’t exist in previous paragraph and read it another time. The situation becomes completely different, isn’t it?

The tiny difference lies within telling the guy what it looks like in the eyes of manager. Telling him what he did wrong. Without that small step both parties can look at the same thing differently.

We often expect others will guess what we’re thinking, which is rarely true. As a consequence there are a lot of misunderstandings like in the case presented above. It’s hard to blame the employee he can’t recognize well whether he meets boss expectation or not.

There’s one simple technique which will allow you to avoid misunderstandings. Tell them. Tell them what your point is and be as clear as you can. Don’t expect they’ll guess. Be ready for a discussion however, since you don’t have exclusiveness for best judgment.

If bosses told the guy what they thought about his performance he’d at least understand why the rest of story happened.

When Something Really Piss You Off

2008-09-29T21:10:00.003+02:00

You know the situation for sure. Someone comes to scold you unfairly. There comes an email which makes you boiling. A phone discussion with a colleague brings nothing but growing irritation. A person in fellow team not only doesn’t help you but is also counterproductive. You become really angry. And then you go off. You put all your anger into your answer. Email, call or tirade. The form doesn’t really matter here.

And that’s the worst thing you can do.

Calm down. Anger doesn’t lead you to anything good. With email it’s easier since you can use the old trick – write it, read it, delete it write it once again. Repeat if needed. A couple of minutes you need to write the email should give you enough time to calm down. With a call or a face to face discussion it’s harder since there’s no rollback option after words have been said.

Note, I don’t advise you to wait for a whole day. Usually several minutes should be enough. Personally I don’t like to leave things which really piss me off to another day. I usually try to react fast enough to remember why exactly I was so touched.

Why? Because when a situation irritates you enough you’re about to erupt it has to be important enough to do something about that. If you wait too long it’s surprisingly easy to forget the problem which isn’t any good since that way things won’t change and the situation will happen again. And it will probably hit you harder since problems tend to grow over time.

To summarize my advice is: when something really pisses you off wait just long enough to calm down and then react, possibly with no emotions.

The Most Important Soft-Skill

2008-09-25T20:58:00.002+02:00

I can’t give you a definite set of skills required to satisfy my needs when recruiting on different positions. However, if you need some clues there I recommend my old posts about qualities of good developers and qualities of good project managers.

Anyway, I definitely can give you at least one skill which is a must-have in my teams. Ability and will to learn. OK, I gave two but they’re tightly connected. If you don’t learn you won’t qualify. Sorry.

I don’t expect to have perfect people in the team. They can suck in many areas and still be great employees, but at this one there won’t be any exception. From this perspective it can be called the most important soft-skill.

If you are learning you’ll become better, more knowledgeable and more valuable for a team. You’ll grow. If you aren’t learning, well, over time there will be many better than you. Why should others invest in you then?

Does Your Product Have a Forum?

2008-09-23T21:01:00.001+02:00

A typical scenario: you have your top-notch application used by greatest users under the sun, but somehow they still have problems with the software. To limit your effort with answering all those inquiries you try to build a place where some experienced users would help others or at least your answers would be accessible by anybody, not just a person who asked the question.

You start a forum for your product.

Great. The real question appears after several months:

Is your forum still alive?

Recently I was advised to take a deeper look at an application (mercifully I won’t give here the name). I opened the webpage went through product description and found official product forum. I thought I’d learn what users thought about the app. Unfortunately the last post was half-year old.

Sorry. That doesn’t work. You could put there a big “Abandoned” banner with exactly the same effect. The forum is dead. And what you do when something is dead? You bury it. You don’t keep the stiff in your living room where everybody can see him.

If your forum isn’t alive just close it. The effect of ghost forum is opposite to what you’d expect. And think twice before starting a forum for the product. Do you have enough users to make it a crowded place? Do your users care enough to help you to keep a momentum? If not the chances are good you’ll be closing it soon.

The rule by the way doesn’t apply to product forums only.

No-Laptop Policy

2008-09-22T20:48:00.001+02:00

That’s a bit of follow-up to recent post about meeting culture. Two of main distracters are mobile phones and laptops. Since our mobiles are sometimes used for emergency purposes we don’t do anything with that. However some meetings will have no-laptop policy. No one enters the room with his laptop. The only exception is a presenter and a machine which will host the presentation.

This should especially work during training session when you need to focus on what’s happening on the floor or you won’t learn much. Yes, I know you have can pay attention to different things at the same time. Or at least you say so. And I don’t really believe you in that matter. Sorry.

If you care more about your emails, go answer them. Outside.

If the training is boring, go exercise more interesting task. At your desk.

If you aren’t interested at all, do everyone a favor. Don’t come.

Of course sense of using no-laptop policy depends of characteristics of the meeting and no one will apply it to every meeting, but these devices are definitely brought much more often that it’s reasonable.

Usability Issues: Seamless Upgrades

2008-09-19T19:31:00.001+02:00

I’ve written about upgrades a number of times yet you couldn’t have expected I’d omit the subject in usability issues series.

Every upgrade is a tricky thing. If you work on desktop application you have to deal with a number of environments and a number of different setups of your product. You also have to find a way to deliver your upgrade to the end-user machine and encourage people to actually execute the process.

If you have web-based application the thing is easier but still you can screw it. User no longer control when upgrade is happening and you can interrupt people in the middle of the most important task they’ve ever been exercising with your app. If you screw something you don’t know about that until your forums become totally hot with discussion about brand new issues you invited with the new version. Rollback is really a pain in the ass since now you have users who already use new features and they won’t be happy if you remove them rolling the version back.

Anyway, no one said upgrades are a piece of cake. Most of the issues mentioned above are about quality of your upgrades but there’s one thing which you should remember about when you build your upgrades strategy. The most annoying thing for the user is when much effort is needed to update the software. Users either don’t do upgrades at all or become disheartened. Make it as seamless as possible. Your users will be grateful.

Whole usability issues series.

Meeting Culture

2008-09-17T21:57:00.002+02:00

Imagine you’re on the meeting. One of attendees in the room. Someone has prepared some presentation or speech and is going through his points.

Then someone starts hitting his laptop keyboard hard since he writes angry answer to some email.

Another girl answers a mobile phone and starts silent conversation which is perfectly heard from the other end of the room.

Two developers in the back row decide to discuss bug submitted an hour ago.

A manager doesn’t care about what’s happening in the room and reads emails all the time.

What the heck? If you don’t care to give attention to a presenter don’t bother to come. If you have something darn urgent finish it before entering the room. If you want to chat go out. Pay deference to work the presenter put into the presentation or speech. And by all means don’t hamper. You’re not the only person in the room, are you?

I don’t play the saint. It happens from time to time I commit above sins, although I try hard not to be notorious with that. Simply because I hate when someone does it. I hate when I try to follow the presentation and someone distract me with their emails and calls. I imagine how I’d feel If I was in the presenter shoes.

The way people act during the meetings, training sessions etc shows what kind of meeting culture your company has and if anyone does anything to improve that culture a bit.

How it looks like in your organization?

Jira Review

2008-09-15T21:50:00.005+02:00

It’s been a while since last software review was published here. This time my playground is Jira. In Wind Mobile we’ve been looking for a tool which could be used to manage each type of issues we have in our projects. After deep consideration we’ve chosen Jira.

Overview

Jira of course follow trendy SaaS approach and is available in hosted version but on the first glimpse I’d say most of their business comes from stand-alone installations in customers’ environments. On general level the rest is more or less typical. Jira is web-based so you don’t need any client except of your web browser.

Talking about functionality you can create different types of issues, which go through different types of workflows. You can get a bunch of reports showing how your projects are going. Pretty ambiguous definition you’d say.

Well, it is ambiguous indeed since in Jira practically everything can be configured. Basing on the “issue plus workflow” model you can build support ticketing, bug tracking, project tasks management, cross-team cooperation and anything else you can think of. As far as you can define custom fields, custom permissions, custom states and custom state transitions you’re able to map practically every workflow you have in your project management methodology.

Strengths

Configurability

One of things which are problematic with different project management software is configurability. Each company has its little differences. You’d say that’s natural, but not for most of software vendors. Each time I look at that type of software I try to map our processes in the application. And I fail. Too many things hard-coded. Too many false assumptions. Too many oversimplifications.

Jira is different. In Jira you can configure everything. I can’t find any single thing which was not in the configuration. OK, there’s actually one thing which needs a bit of coding but that’s not a problem since there’s open API and good documentation.

Speed

Web applications suck in one thing. Usually they’re totally crappy when you look at their responsiveness. All that nice UI comes for a cost. You pay for it with your time each time you wait when next screen will finally load. Jira is fast. Sure, it couldn’t match with desktop software but for the web application speed is very appealing.

Ecosystem

With open API and great configurability you can find a lot of free plug-ins adding new functionalities to Jira. We’ll definitely use risk management to give one of examples.

Of course you need a base of customers to build an ecosystem and I don’t expect fresh applications to have something similar build around them. But you need to enable that with your software too. Jira accomplishes the task and since it’s already an established piece of software you can use a lot of others work to improve your own installation.

Feature range

You can say feature range is rather basic. However with all configuration options you have you can cover almost every scenario you need. I found none of typical shortcomings. History, security, notifications, workflows... Everything is there.

Source code

Buying stand-alone version of Jira you get its source code. Now, nothing can stop you to force Jira to do exactly what you want. Although we don’t plan to mess with the core of the code it gives you safety even if somehow Atlassian stopped to support their product.

Weaknesses

Price

We’ve chosen enterprise version, mainly for multiple workflows feature. It costs $4800. It’s definitely the most expensive application we’ve considered. The cheapest hosted version (limited to 25 users) starts from $299 monthly which is quite crazy if you compare it to other alternatives.

Personally I wouldn’t go for hosted version since it’s unreasonably high when compared to stand alone enterprise version.

Anyway, the only thing I can add: Jira is worth its price.

Small usability flaws

Main thing is unintuitive control placement on the most often used screen – issue details. I still can’t get used to see a part of details on the sidebar, another part on central area and a part available only when I edit the issue. I guess it can be configured, at least partially, but I wonder how they could come with that as a standard interface.

Other teeny things are standard lists and a dashboard, which could be better. This time we’ve been able to change standard screens easily, so I shouldn’t complain much. I just wanted to lengthen a bit weaknesses chapter.

The whole interface isn’t very nice, but as far as it’s usable I don’t care. And to be honest it’s hard to cavil since usability of the UI as a whole is very decent. And ugly UI doesn’t automatically mean bad UI.

Summary

Usually that’s the place where I complain. With all cool ideas developed in the product final effect is usually gimpy. It’s easier to work on cool features instead of adding that boring history or polishing security model to suit complex scenarios.

People form Atlassian did the homework well. I have to admit I fell in love with Jira. It’s fast, reliable and flexible. Every important feature is on the board. I can’t think of any scenario we wouldn’t be able to cover with the application. It’s great. The only thing I’d change is the price, but hey, you can’t have everything.

With business approach Jira creators have it’s not software for small organizations. Small organization should find other suitable products which are also cheaper. Jira in stand-alone environment also requires some time form its administrator especially at the beginning. You can avoid that choosing hosted version but in my opinion stand-alone version is much better choice.

Anyway if you have 20+ people in the organization and you look for project management software consider buying Jira. That’s a good choice.

Usability Issues: Easy Installation

2008-09-12T21:08:00.001+02:00

Imagine you’re a user. You get a piece of brand new software. You want it on your notebook. What kind of installation process you’d expect?

None. You want to do nothing and application should work. OK, you can type something like www.google.com, but that’s all.

And for desktop application? Not much more really. Just click big install button and see “installation complete” message.

How different the reality is. My friend tried lately go through initial setup of Windows XP on his new toy. Tens of updates, hundreds megabytes in downloaded files and numerous restarts. At the very moment I’m respawning my Windows machine as well and I share his frustration.

Don’t go that way. Make your installer as simple as possible. If you necessarily need user to accept license, show it and let the rest be made automatically. Put somewhere “advanced installation” button for geeks who want to know where each byte on their hard disk is placed, but make the standard path in the simplest possible way. At least 9 times out of 10 simple track will be chosen.

If your app is web-based you’re even more fortunate. Avoid forcing users to receive their emails if it’s not necessary to use the service. If it’s not possible make the process (you already know) as simple as you can. Let people play with your application, not with its setup process.

Installation is a necessary pain in the ass for user who wants to use the application. This time it’s not about chasing the rabbit but about catching it.

Whole usability issues series.

Celebrating Success

2008-09-10T21:23:00.002+02:00

You set a goal. You find a way to achieve it. You try hard to follow the plan. You change the path when obstacles occur. You finally reach whatever you’ve planned.

And again from the beginning.

Stop. You missed one thing. Celebrate the success. You’ve done it. It doesn’t have to be big prize or a great party. Meade Rubenstein advices in her post about solving problems: “At least have a cold beer once they're resolved.” The same idea is brought by Lech when he talks about gratification: “Even the most teeny tiny success deserves celebration.”

With no celebration you’ll be more and more tired with getting just another challenging task instead of a bit of rest. Let yourself be happy for a moment with what you’ve just achieved. Show yourself it was worth the effort.

You’ll feel better.

Ethics Dilemma

2008-09-09T20:55:00.002+02:00

Craig Brown brings an ethics dilemma for project managers. How you would act if you had a team member from Afghanistan or Vietnam and your company had won multi-million dollar project for US agency. Would you as a PM let the team member go to follow US law or decline the contract or maybe break the law?

I think the question isn’t addressed well. When a company wins a multi-million dollar contract no one asks project manager about problematic person. The decision is made way higher by senior management.

For me the question is different. What would you do if your bosses decided one of your team members will be moved somewhere else for non-merit reasons? Just to keep this big deal done according to US law. You’re a PM and someone answered the question brought by Craig. Would you get over it and just do what you’re paid for? Would you try to do something else? What?

Usability Issues: Learning Curve

2008-09-04T21:43:00.002+02:00

OK, you’ve done your homework and your application is filled with different usability features. The design is clean, all controls are set properly, tab order and keyboard shortcuts are double-checked. And when you look at the way fresh users approach the application you’re confused.

They don’t use all that stuff.

They don’t because they don’t know how. You haven’t taught them. While they work with the app they’ll step through learning curve – they’ll learn more and more how to exploit better the softer they use. Your task is to make learning curve possibly narrow.

Some things will come with time. If button placement is consistent I’ll expect the same function buttons (like save, cancel, delete) always in the same place. Some things you have to teach. Show which keyboard shortcut leads to which function. As an example quite a good work is done in new MS Office which displays letters on each button after shortcut was used to change tab.

You can throw in some advices like “you can easier do this using that” but my opinion is “tip of the day” method doesn’t work well. You should rather put them somewhere on the screen but in a way they don’t hit the eyes and don’t waste precious working space. This is done nicely in Google Reader where last Google Reader Team Blog post is displayed at the end of the home screen.

There are many ways to improve learning curve. All you need to do is to remember to help your users to learn your world-changing app.

Whole usability issues series.

PM Talks

2008-09-03T22:19:00.001+02:00

I spend a lot of time with project managers. Heck, I sit with 4 of them in a room. I want it or not I see how they manage their projects and their project teams. I see how they talk with people.

Each of them does it differently. However there’s one thing which is common – there’s a distance between a PM and the rest of a team. People consider PM as a kind of boss. That has of course a bit of truth since PM is the person who manages the project and at least partially the project team. There’s another reason too. PM is usually a person connecting project team with a client, so he should know what client wants.

Now, PM can use this “power” to get what he wants. Change this interface because it has to be like that. Add this feature because it is crucial for the client. It won’t be accepted during tests. We have to do it different way because business requirements say so.

Each PM sometimes will go that way. Sometimes it’s just easier. Sometimes they don’t see any other way to get what they need.

My advice is: avoid that whenever you can.

If you’re a PM you probably have more knowledge about project than any single person in the team. But it doesn’t mean you always know better. It doesn’t mean you have more knowledge than all your team gathered in one place.

There’s a bunch of better options:

• Discuss. Tell why you think client won’t agree. Go deeper in the discussion. Today we went from trying to decide what columns we should add in the database to description how small vendors should craft their business offers for big clients. It happened during technical session with developers and I don’t consider that time as wasted.

• Listen. We tend to listen to only those arguments which support our opinion. When our position is stronger than our adversary it’s even easier. It’s more difficult to listen to others’ arguments and be ready to change one’s mind.

• Ask. With the distance PM has with the rest of the team sometimes it’s even hard to get someone’s opinion if you don’t ask. Hey, she runs a project so she knows better, right? Why should I throw in my ideas then?

• Delegate. Some decisions have to be made but it’s not a PM who is the best person to be a decision-maker. Programming details. Tools used in development. Approach to testing. The list is long. When the team expects you’ll have all the answers try to delegate finding some of them on others. When encouraged people will be more creative than you’d expect.

Remember, each time you use “I know it better” approach people will less likely participate in decision making process. You’ll end up in more “I know it better” decisions which are very rarely the best possible option.

During Discussion

2008-09-01T23:37:00.002+02:00

Next time you’ll be in the middle of discussion try to:

1. Agree with other party argument when they sound reasonable. At least once.

2. Find new points to support your position when you believe you’re right. At least once.

3. Propose completely new model when you don’t seem to reach consensus. At least once.

4. Stress statements of each party you agree with when you’re an observer. At least once.

5. Look for satisfactory consensus instead of keeping as many own points as possible. Always.

It will help.

Usability Issues: Shortcuts

2008-08-28T18:24:00.001+02:00

Your application has shortcuts. Every piece of software has some. Ctrl+S when you want to save something. Ctrl+O to open something. Ctrl+I to turn on italics or Alt+R,S to run spellchecker in my word processor.

Sure, no one knows all of them but every time people start using specific function very often they try to do it a bit faster. They won’t be moving their mouse lightning-fast so they start to use shortcuts.

If the application has some.

Shortcuts are not for fresh users. They are for users who know what they want to do and how to do it. As far as you care for experienced users too you should double check if all your functions are accessible via keyboard shortcuts.

That’s the same kind of situation as with tab order – with low effort you avoid frustrating your users.

Whole usability issues series.

Another Advice About Agile

2008-08-21T16:14:00.000+02:00

Steve McConnell brings his opinion about agile software development. The message which is delivered is simple: agile isn’t the answer for all questions, sometimes it works well sometimes it does not.

I think one point clearly shows why agile isn’t always appropriate:

“Some businesses value agility, but many businesses value predictability more than they value the ability to change direction quickly. For those businesses, becoming more Agile is a second level consideration; the first level consideration is how to become more predictable.”

If you deliver software for mobile operators or other big organizations you should be familiar with that one. In their ideal world everything is delivered as it was stated in the order: on time and within functionality. They know they will have to pay additional fee for changes which came out during implementation and they’re OK with that. It would be much bigger problem if they were sure all changes will be implemented in the project but it would be hard to say when exactly the project will be finished within ever-changing scope.

For them agile isn’t the answer.

10 Rules of Negotiations I Follow

2008-08-20T19:48:00.002+02:00

I used to say I hate negotiations. I always considered myself as rather poor negotiator. Lately I had several occasions to negotiate different things. And I have to say it brought me some fun.

The way I exercise the task seems to be non-standard for people who makes their living negotiating, e.g. salespeople I know. I follow several rules.

1. Be ready to leave negotiations without setting the deal. Whenever you’re determined to reach consensus at all costs it’ll cost you much. I’ll always try to sit behind the table with two possible options at the end of the process: success or failure.

2. Try to put yourself in other party shoes. Quite typical approach to negotiations is to look from a perspective of your own nose and then to move slowly step by step until your position is acceptable for the other side. I don’t agree. I prefer to look for win-win scenarios from the very beginning. Unless you look at the proposal with the eyes of the other party it’s very hard to judge its value for people you negotiate with.

3. Don’t waste the time. Yes, I know it is said the time pressure is an enemy of a negotiator. I believe in different approach. If your points are written in the stone – show it. You don’t necessarily have to start with $2000 if you want to end at $1250. You can start with $1300 and show you aren’t willing to move much. You’ll end up having more time on other things.

4. Set own goals. Once I had a chance to ask my fellow negotiator what’s his goal. “I don’t know” wasn’t the kind of answer I expected. I always try to set my goal at reasonable level and it is fine for me when I reach it. I don’t try to push further until the other party brakes negotiations or reject to change any point. And yes, I know that my approach results with some contracts which could be improved a bit. But yes, I’m happy that way.

5. Avoid unreasonable offers. If you’re a seasoned negotiator you’ve seen that a lot – offers which you know isn’t acceptable but is shown as a “negotiating position” or “opening position”. Avoid that. If you’re lucky it can result in lengthening the process, but the other party can feel like they were slapped in the face too. Unless you’re trying to insult people on the other side of the table or you love to waste time it isn’t the greatest idea.

6. Be well-prepared. If you can be caught on the numbers you aren’t well-prepared. You should always know which numbers you show, how you’ve come to them and why you think they’re reasonable. That way even when situation changes you can always recalculate your offer on the fly.

7. Call for a brake whenever it seems you don’t move further. It doesn’t hurt. It doesn’t weaken your negotiating position. It doesn’t moves you back. It gives you a chance to restate your goals or rethink your argument. If you’re a part of a team it gives you a chance to make ad-hoc adjustments in your strategy.

8. Be honest. I don’t see a point in presenting some fake goals or pretending to put an offer you know you’ll adjust soon or to show different reasoning than it really is. Being honest during negotiations builds your reputation and strengthens offers you put on the table. It also gives other party better understanding of your point of view. Beating about the bush is somehow expected but gives you (almost) nothing.

9. Be constructive. Sometimes it can be clearly seen you can’t reach consensus with assumptions both sides have made. If you keep repeating your arguments you don’t move further. However you can try to look for a completely different model which will give you some area where you can meet.

10. Prioritize your goals. If something is really important try to agree on that point and then to move to other ones. Usually you have a number of different parameters which are connected with each other. Sometimes much more important than a price is a schedule. Remember, usually different parameters will be pointed as the most import by each party so it can be fairly easy to reach consensus.

Don’t treat it as top 10 sure-shot negotiating techniques although for me they work fine. Although it isn’t standard negotiating approach it shortens the process and brings me satisfaction with results I achieve. I can hardly stand several standard negotiating techniques which make me boiling because of time wasting. You don’t get a prize for a number of hours you’ve spent on the process.

Do They Know What’s Important

2008-08-15T22:47:00.002+02:00

I haven’t pushed it because I didn’t know it was important.

I’d call if I knew it was a high priority task.

Wasn’t I expected to complete other things earlier?

No one told me it has to be done by Monday.

And so on.

Consequences can differ. Maybe a couple of hours of delay if the task is on the critical path. Or lost deal if someone failed to prepare the offer on time.

The question is:

Do all of team members know how important is the task?

The answer is:

Most likely, they don’t.

When you talk about top priority tasks it’s not enough to tell it at a team meeting. It’s not enough to state it at the beginning of a project. It’s not enough when a project manager knows it. It should be repeated until people know they could call their CEO at midnight to tell him when something went wrong.

Does your team know what’s important? All of them?

Usability Issues: Clean Design

2008-08-14T20:59:00.000+02:00

This one can be a bit controversial. I believe in simple design. That way user is a somewhat forced to go into most important options/functions which are displayed at the screen.

Sure, most of applications have more functionalities than simple search button, but still it is possible to fill the space with clean working area hiding most of options behind toolbar or menus. I think web browsers are quite good at it. Main area filled with web content, tabs boosting application usability, toolbar with 5 buttons and 2 edit boxes and menus hiding all the rest.

The other approach is to put it all on the sight. Take typical news portal. A number of lists with different content, a growing number of ads, blinking background, pictures etc. All the crap is there and suddenly you can’t find your favorite column. It’s always tempting for marketing to put as much as possible on the starting screen to show all the features of the app.
I don’t buy that. I believe the clean design is much more useful. However like I’ve said there are different opinions about this one.

Whole usability issues series.

Quality or Price?

2008-08-11T21:35:00.002+02:00

Our beloved marketing team in Wind Mobile found very interesting news lately. MarketingSherpa published a poll which shows why customers decide to leave vendors and which reasons are pointed by vendors in the same situation.

Two main conclusions:

Customers leave because they’re not happy with service they got.

Vendors know nothing about real reasons for losing their customers.

The poll shows what I always believed was important: the quality. It doesn’t bring an easy profit to salespeople since you need additional costs to achieve high quality. It isn’t a piece of cake for tech people either since you need to put additional effort to whatever you do and generally care more. Yet somehow, people on the other side are able to appreciate that.

You can say maintenance team doesn’t decide which vendor will be chosen. You can say the next project will be delivered to a different project team. You can say the price is the only factor.

Bullshit.

Maintenance team doesn’t decide, but is asked for an opinion. Project teams communicate between each other and they actually know what the current vendor rating is across the company. Price is never the only or the most important factor in IT. Customers always weigh functionality, level of fantasizing, track record and actual content of the offer. At the end of the day it’s easier to negotiate the price than a track record. You know, the latter won’t change just because someone says so.

The price is rarely the only matter of making important decisions, although I know situations when it plays the main role. But even then differences must be significant to counterbalance other factors.

Even when your salespeople tell you a different story.

Usability Issues: Like Good Old App

2008-08-08T21:50:00.001+02:00

If you asked your users how your application should work how they would answer? I guess:

Like our good old app, but better.

The flow of operations shouldn’t differ much. Placement of often used functions should be similar. Shortcuts should be connected with the same operations.

If you have some kind of industry standard application in your area, don’t hesitate to base on that one. If not, well, look for those applications you want to compete with.

Remember you most likely don’t bring something totally innovative which can’t be compared with any other software being on market for some time. Remember people like what they know or rather people feel comfortable with what they know. And making your users uncomfortable doesn’t make user experience skyrockets.

Whole usability issues series.

Tough Times Forge Great Teams

2008-08-04T19:30:00.002+02:00

I have a small exercise for you. Describe several attributes of a great team.

Dedicated people?

“One for all, all for one” type of attitude?

Friendly atmosphere?

Being helpful to each other?

Focus on achieving team goals, not personal ones?

Strong personal relationships beside professional interactions?

Ability to deal with difficult situations?

I guess all of them are true. The funny thing is those attributes are exposed more likely whenever tough times come. I know several great teams which were born when no favorable circumstances could be found.

A team with commonly disliked boss. Suddenly it appeared the team wanted to show not only they can manage their task with no boss at all, but even with a boss who disturb instead of help. Engagement skyrocketed. Teamwork went on new level. They used to say the sky was the limit. They should just leave but instead they choose to resist. What an irony, soon after they got what they wanted to – their boss had left – the team scattered.

A technical team which worked in difficult company environment. All decisions were driven by salespeople with no balance from the other side of the barricade. Unreasonable project decisions were their bread and butter. No one tried to understand all the technical issues. Schedules were cut in the half with no rational reason. If you add some financial problems of the company the environment should force anyone to leave immediately. Another time people chose to fight. Despite tough time they managed to complete very challenging task. They built strong personal relationships. They created friendly oasis in hostile environment. However, since things haven’t changed for a longer period of time they started to look for a better future elsewhere.

Becoming a great team is a way of self-defense. If people acted as they’d do during peace time they’d have to leave soon. Leaving a job is almost always a hard decision to make so people start to be engaged a bit more. And a bit more. And a bit more... Other try to follow and suddenly everyone works as he was on steroids.

A bad news for those companies which try to forge great team that way is you never know when it ends. Patience isn’t endless. People will leave and you’ll lose much more than you’d thought – an additional value brought by their greatness.

Building a great team during normal time can be paradoxically more difficult, however that way the results last much, much more.

Usability Issues: Quick Start

2008-07-31T22:25:00.001+02:00

There are two kinds of users. Those who want to understand how the darn thing works up front before they start playing with the application and those who expect to start the darn work as soon as possible.

For the latter vendors prepare sometimes something like a quick start scenario. Some predefined settings which allow avoiding long and dull configuration process. Computer games are a great example. Very often you can choose to set every detail of your character/team/environment by yourself or you can choose among one of predefined sets.

There are great examples in different areas too. Our financial and accounting application has test database installed by default. People can check how it works on test data without affecting production database.

Of course quick starts aren’t applicable in every application – usually they are useful whenever some pre-configuration must be made by the user. However this kind of approach you can find even in Internet Explorer with predefined list of favorites.

Whole usability issues series.

Easy versus Hard

2008-07-29T21:19:00.003+02:00

It’s easy to criticize others work.
It’s hard to be fair yet critical when it comes to judging own work.

It’s easy to point others failures.
It’s hard to admit own failure.

It’s easy to over-interpret others points in discussion.
It’s hard to say sorry when you go too far with your judgments.

It’s easy to work from this point to that point.
It’s hard to look always for a broader perspective.

It’s easy to become angry when things go wrong.
It’s hard to overcome angriness and look for constructive solutions when things go wrong.

It’s easy to look for excuses.
It’s hard to look for solutions.

It’s easy to say.
It’s hard to do.

It’s easy to say “no.”
It’s hard to look for a compromise.

Just a reminder. Mainly for myself.