Negotiating Schedules with Customers

There’s a thing I was thinking about and discussing a lot these days. When you take typical project for a big company the process looks usually like that:

• We want to buy a project doing something. Deadline would be end of the next year and it should cost no more than half a million.

• Let’s fire the formal process – RFIs RFPs, all those blah, blah, blah. There’s heckuva lot of time.

• Oh, those two offers look the best. We can have the solution delivered in 4-5 months since the agreement is signed. Pretty cool. We still have a quarter to sign that darn thing.

• No need to hurry, we can spend another half a year squeezing vendors (on the last stage the chosen one) to lower the prices, add features and shorten delivery time.

• Oops, it happened so, we used most of available time negotiating the offer and won’t make it by the end of the year if we follow the original vendor’s plan. Maybe dates can be squeezed more by a couple of months. Oh, yes, they can.

• Hey, the vendor singed the schedule which was cut by a half. What a stunning success!

• That darn vendor can’t keep the schedule. They’re always like that. I told you on the very beginning they lie with dates they’d shown.

Yes, the customer is the boss. Yes, the vendor dances as the customer plays. And yes, the customer is the one who actually pays the money. But above strategy isn’t the best one I’ve ever seen. Most of vendors agree to whatever schedule is requested because they want to settle the deal. It usually ends up with big deadline overrun which costs both sides.

I’d understand it if it happen once or twice, but sometimes I think that’s industry standard. I’ve seen too many projects squeezed by a half which, at the end of the day, had 200% time overrun. I’ve seen too many projects where “signing the agreement” milestone was moved several times while “ready to acceptance tests” milestone looked like it was written in the stone. I agree the situation is organized in a way which kicks the vendor more than the client, but that’s still a lose-lose scenario.

What is your experience in that area? Do you often work for customers who share accountability for deadlines with the vendor?

Screwed Software Upgrades Saga, Episode 152

Haven’t I mentioned I love web-based software? Yes, I have. Haven’t I mentioned upgrades of web applications are smooth and easy? Yes, I have. Haven’t I ranted about those screwed software upgrades examples? Yes, I have.

Ops, they did it again.

I really like Google Reader. Now, with powerful combo of standard version on steroids (actually on Google Gears) and mobile version it’s complete and I don’t even consider moving to another platform. They upgrade versions seamlessly, nothing you need to do. They add those little features, you know, those which look tiny, but save you a lot of time and make you thinking they were on board since The Big Bang. Like that little dropdown which allows you to attach a newly added rss channel to one of groups you use. So simple. So useful. A masterpiece.

And then, they just take it out. It’s gone. It’s just not there any more.

Yes, I know, they’ve just added dozens of new features. Actually I use none of them. I don’t care. The thing I care is they’ve taken one of those several functions I use. OK, I understand someone can overlook a bug and software is shipped with one, but they’ve cut out whole functionality. It looks like no one tried to add a blog to Reader’s list during testing period (yes, I know I exaggerate, but it was my feature, my preciousss).

Lesson learned is simple – taking upgrades away from users makes it easier (well-known and controlled environment, limited backward compatibility issues) but also raise expectations. You can’t upgrade only those 95% of users who won’t be frustrated allowing the rest to keep an old version. Every forgotten feature becomes a pain in the ass, as soon you have to face negative buzz from unhappy clients and you spend time on boring quick patch instead of adding more new cool features. Paradoxically the more easy it is, the more careful you have to be.

How to Make Users Happy

Most software vendors struggle to make their software better. We add functionalities, we improve performance, we fix bugs. We follow strategic vision which tells us where our application sucks... I mean is very good but should be pushed closer to perfection. Unfortunately it is the vision which sucks so often because we focus on wrong areas.

Yes, new features make sales easier but they rarely make users happy. Generalizing a bit, most users don’t use the most new features delivered in a new version. Users follow their old, well-known paths. If you want to make users happy you should track those paths to see where they can be improved.

I see many examples how it is screwed up these days. When I shoot at Google Docs or OpenProj it is because my frustration grows when I try to follow the most basic, yet the most frequently used, tasks delivered by the software. And while I like both I still come back to their old-school Redmond-based alternatives.

Similar situation I found today with MindMeister. It is web-based mind-mapper. Probably the nicest-looking web-based business software I’ve seen so far. It looks nice, is free (for basic features) and delivers functionality you need from that kind of software. Nothing more I could have expected. Except of doing the basic things right. The frustration can appear quite fast when you can’t delete a node in a mind-map or change connections between nodes, no matter how hard you try. These are the most often used features. They should work. OK, they work. Most of the time. Actually they work 99% of the time. But that’s not enough.

Although I use mind-mappers rather rarely I like MindMeister much. It’s a piece of well done work. Unfortunately small issues affect a bit that nice picture. They are small but happen in the area where they should not. The one which is the most frequently used.

That’s just another example that when you want to make your users happy (or happier) you should adjust your vision to include the work on the things which your users use the most often. With complex application the quality and usability can differ depending on areas/functions/modules we consider. Focus on those which make your users frustrated with everyday use and fix them. That won’t bring you direct sales (as new features would) but content user will spread the word.

And the good user is the happy one.

Don’t Look Back

When a team faces a problem I see quite often a tendency to look back to find who is guilty in triggering the issue. This attitude can be recognized by questions:

• Who did something?

• Why it wasn’t cross-checked by his supervisor?

• What was promised to a customer?

• Why didn’t they prepare an ass-cover?

• How you could allow that?

That’s all about the past. And most likely that’s all about witch hunting to find the one to blame and prove you are not the one.

As we’ve been learned by experience above process rarely brings a clear message. He failed. She misunderstood the task. They forgot to agree something. And even in those rare examples that kind of knowledge is most likely useless. Yes, this time PM sucked. So what? Are you happy now? We better go back to find the solution, then.

Anyway, usually you end up with some vague information pointing at misunderstanding between several persons, unexpected issue which popped up in the worst possible moment or a series of events which you can’t blame anyone for, yet they brought you to the placed where you are.

That’s all utterly useless and completely wrong.

First you lose time for witch hunting instead for spending it on looking for a solution. It’s like looking for arsonist instead of firefighting when you see fire all over the place. Very clever indeed. Second you teach your people not to take the risk and to minimize the chance to make the mistake and, as a consequence, to slow down their learning curve. With that attitude in extreme example you can end up with people refusing to do anything until very detailed specification is delivered (and yes, I worked with that kind person some time ago). While you can count time spent on useless activities (and accept it if that’s your will), impact on creativity, commitment and atmosphere in the team is both hard to measure and really painful.

Temptation to follow the witch hunting scenario is strong (several years ago you’d see me quite often in the role of an inquisitor), but really, you have better choices here. I usually try to focus everyone of fixing the situation (firefighting), leaving looking for a reason why it all went wrong (tracking arsonist) for later. That usually satisfies both those who can’t live without looking for ones to blame and those who remember about learning from own mistakes. Quite often when the pressure is taken off no one needs to witch hunt any more and you don’t have to point fingers on each other. The learning part you can make on post mortem sessions where the atmosphere is far from blame game.

Interesting thing is that even in environment focusing on today and tomorrow instead of yesterday I see so often people actually expecting they’ll be blamed for overrunning the schedule, wrong estimates, screwing up the task, bad weather or manager’s hangover. Maybe it lays so deep inside of us, we can’t fully resist?

How Often You Should Run Team Meetings

I guess many managers have their own answer to the question how often they should have their team gathered in the room on a cyclic meeting. I guess answers varies from “Never, I hate those people.” to “Twice a day, they’ll get lost without my guidance.” Agilists will shout: “Every day, but 15-minuters only. And burn all the chairs in the meeting room.” Old-fashioned managers will go rather for multi-hours sitting meetings where they can play all those ego-boosting office wars.

OK, that’s the bunch of options, but yes, I have my own. To be honest I put the question only to give my favorite answer to any question (“Do you want a beer?” question not included). The answer is:

It depends.

By the way, one of thing why I’m not a big fan of agile methods is because they’re highly formalized... Yes, they are... Yes, they are... Yes, they... never mind. I don’t agree you have to meet everyday no matter what project you run. I don’t agree fortnight is the best cycle length in software development. It depends. It depends on the team, the project, the customer, resources and goals. Those things, including meeting frequency, can’t be standardized.

Coming back to the question how often you should run team meetings... There are few factors you have to consider when you gather the team, or part of it, on the meeting.


• How fast information is overdue. When you have two-week development cycle (no, I haven’t said it’s all wrong) meeting every day or every two days to summarize progress is a good idea. Having a meeting once during the cycle is definitely not so clever.

• How often you waste time of the team. You force developers to leave their beloved PCs while in the flow of inventing new ground-breaking, cutting-edge, world-changing algorithms. You sit with those who came on time waiting for those who are always 5-minutes late. Yes, every meeting, even with the most creative outcome, is at least a bit of a waste of time.

• What outcome is expected. And when you want to have it on your desk. You don’t try to rearrange development tasks assignments during the last week of planned development phase. You do it during the second week, because after the first one you have first lags. OK, I know, with two-week cycle the second one actually is the last one. If you need some work to be done after the meeting you need to allocate the time for that. Even the most skilled architect won’t create technical design document of the high-availability real-time system within a day.

• When all parties are free. That’s the easiest one. At least for the most of managers I know. You don’t run meetings just for sake of running meetings but to execute some actions on some people: giving information, receiving information, assigning a task, asking a question, giving feedback etc. You want it or not, as far as you don’t have another interested party on the other side of the table it isn’t very successful. So take a minute to check their availability before sending invitations.

A couple of factors drive you to have the meetings faster/more often, another couple quite the opposite. There’s really no rule of thumb here. With tight three-week development schedule, we meet twice a week with developers. When talking about meetings summarizing status of all projects we run them once a week, but we keep their frequency religiously. With general team meetings, where we share information about things everyone works on, we try to follow once-a-week schedule, but without any pain we cancel events whenever it’s hard to make it. Individual face to face meetings with people from my team I have every time they (or I) feel like having one.

With other team and other projects it would be different. You have to decide yourself how often you need to have team meetings.

OpenProj Review

Several days ago I received a message from Marc O’Brien, vigorous CEO of Projity. They are launching new project management tool – OpenProj. OpenProj is designed as a cross-platform substitute for MS Project. Unlike web-based Project-ON-Demand from the same stable, which I’ve already reviewed here, OpenProj is a desktop application being close copy of Microsoft origin.

General

As OpenProj is a desktop stand-alone application you need to install it first. No issues here. On the first glimpse interface looks familiar enough for any MS Project user so there shouldn’t be any significant problems on the beginning. Of course there’s an option to import file from MS Project. It loads tasks, resources (Project-ON-Demand didn’t do that) and connections between resources and tasks. Nice job done here as the application is expected to migrate users from Microsoft solution. One more thing to notice: Projity-based application works (at least for now) as a stand-alone application only – there’s no collaboration features on board. I don’t say it’s automatically wrong – quite often people just don’t use them.

I was able to import an old mpp file. I was able to create simple project quickly. Generally these are strengths of OpenProj, yet these are also must-haves on the market the solution is addressed to.


Issues

Definitely OpenProj is still far from perfection. I don’t say here about feature range, which is quite OK (even too wide for me), but about the quality of existing functionalities. There are three areas which should be improved:

1. Editing area
This is a sin which I see so often (Google Docs is one of my favorites here), that I’m not surprised at all. When you try to fight with market leader, whoever it is, you can’t deliver worse quality, especially in the area which is used the most often – the editing area. OK, what’s wrong here?

• Ctrl+C/Ctrl+V works when used on task name, but does not when used on resource name.

• Del on resource name on Gantt chart deletes the whole line instead of clearing resource name cell.

• Insert on tasks list adds new line but focus is set not on the newly added task but on the following one.

• On the task list there’s no dropdown to choose resource from.

• Every time the cell is clicked it enters “edit mode,” what makes navigation much less intuitive.

These are only several examples which popped up on the very beginning. Generally typical user converted from MS Project will quickly call the OpenProj unintuitive and unfinished, because it doesn’t work like we used to.

2. Organizing projects
OK, that’s the clue of the whole thing. You enter all those resources, tasks and then you need to create something what looks like a project. You switch tasks, paths, relations etc. And you get frustrated as you still get no software which makes the task more pleasant. MS Project does really poor job here, but unfortunately OpenProj isn’t any better – it fails to keep even Microsoft “standards.”

• When adding relation between a couple of tasks by selecting them on the list and choosing a chain icon, the predecessor will be always the one which is higher on the list, no matter which one you’ve selected earlier.

• When working with “percent complete” column every click on that column outside the current task list automatically adds a task what brings a mess into the project.

• Changing a day to non-working time doesn’t affect existing tasks in any way, while new ones know there’s another free day.

And yes, that list isn’t complete. These are just few points I’ve noticed during first hour or so reviewing OpenProj.

3. Interoperability
OpenProj will definitely work in “mixed environments” where a part of people will use MS Project and a part (hopefully) OpenProj. There’s an option to import an mpp file. But why the heck there’s no option to save the project as one? Wanted to make MS Project users’ life harder or what? Hey, they rather stop using OpenProj than move to use an xml files instead of an mpp format. Yes, I know xml is more open etc, but mpp is a standard, you want it or not. If I send xml file to my customer he’ll ask me to send a “normal” mpp file.

Cool Things

As with other Projity’s products cool things lies in concepts standing behind the development, not it the quality of results.

1. Price
OpenProj is basically free. MS Project is not. Nothing more to comment here.

2. Cross-platform
Linux, Unix, Mac and Windows. Definitely pushes the market borders further, although as I’m the Windows user, I can’t say either what is the competition on other platforms (if any) or how big can be the impact of OpenProj here. I haven’t played with the Projity’s new child on platforms other than Windows so I can’t say if it works better, worse or just the same.

3. Acceptable quality
Having vented all my rants above I think OpenProj has acceptable quality for now. It’s definitely less intuitive (yes it is possible) than MS Project and I expect the managing of complex project will be hell, but industry standards in the area aren’t very high. You can easily figure out basic things, the rest wouldn’t be a piece of cake anyway. Remember that’s the first version of OpenProj – according to the law of version 3 I should wait a bit to see a mature product.

My opinion

Projity definitely tries hard to cut some of project management tools market from Microsoft. After web-based Project-ON-Demand they try on another front. I don’t share Marc’s optimism that OpenProj will be enabler for the part of the market which hasn’t used MS Project because of its price. I see much work is to be done in future improving the application.

Projity’s path isn’t easy as they’ve chosen demanding competitor and, to be honest I don’t really believe they can stand a direct confrontation (I had a short discussion with Marc about that). However I’d look for a chance in a niche where MS Project rather won’t come – the lite version. I know, I was mentioning that in the Project-ON-Demand review, but that’s the thing I still miss.

I’d love to see lightweight solution which brings limited functionality but do it well. Tasks, resources, connections, simple Gantt chart and simple cooperation features. This is I believe the real market enabler and the place where you don’t have to fight the Redmond giant. At least not on a daily basis.

15 Ways to Be a Good Boss

1. Give credit to your team whenever they’ve earned it. Publicly.

2. Don’t be too fast with criticism. Wait until you calm down.

3. Don’t wait with feedback to next performance review. That would be too late.

4. Be team’s advocate in front of your supervisors. And vice versa.

5. Let people find consensus instead of telling them what to do. Whenever possible.

6. Enter when you see a conflict. Be fair no matter who is engaged.

7. Be open, honest and straightforward. More often.

8. Listen to the team. They have good ideas.

9. Let people be accountable. Whenever they can.

10. Don’t be afraid to make bold decisions. They pay off.

11. Make though decisions when you believe they’re right. They’ll backfire when not made.

12. Don’t panic in any situation. People count on you.

13. Take the responsibility for the team’s work. Their mistakes are yours.

14. Find the time for your people. Whenever they need it.

15. Cultivate teamwork and team chemistry. Individuals and their interests can destroy both.

Ask (Kindly) for Help

In project management unexpected problems are, well, expected. You know someone will kick you, the questions are: who, when and where? Hardware vendor, right now, sending dead parts. Subcontractor, next month, not giving a damn for bugs submitted to their part. People from support team, since Tuesday, ignoring your desperate pleading for work around of critical bug. Feel free mix parts of answers to get the right combination.

Possible Reactions

There are five possible choices how to deal with those issues. Each of them can suit specific situations.

1. Do nothing. Wait patiently for the issue to be fixed. If you don’t really care, why spend energy and time to move things faster? Why make all the mess?

2. Take it over. If you can. All those computer boards manufacturing looks easy. With soldiering iron and several chips you should make it. Okay, okay, maybe not so easy, but with software development this scenario is possible and quite often works fine.

3. Blow out. Express all your anger, tiredness and helplessness yelling at the other side. Tell them they should rather make ballpoints instead of developing software (as I was advised recently). Oh, sure you won’t make any friend that way and you hardly get any help, but you should feel happy at least. You told’em! Your ego's condition should skyrocket.

4. Ask for help increasing pressure. Let them know the issue is important and it can affect both your business and theirs. Show them context. Don’t expect they understand. They most likely don’t. Explain them like the grandpa to the cow on the balk. Keep it strictly professional and do it kindly. No need to show emotions.

5. Ask for help somewhere higher. If the above doesn’t work, and it just so happens quite often it does not, repeat but address the communication to someone who is mightier. The Big Boss, manufacturer instead of vendor, Father Founder and/or all saints. Don’t be discouraged because you’ve already heard everything possible was done and you won’t achieve anything more. Funny thing is, the higher someone is the more he cares about the opinion about the company and the more he can do. Both things can be very helpful.

When you have to deal with the really serious issue, go for number 5. Name the Most Important Person you can contact and send polite yet pressing message showing briefly all the background and asking (kindly) for help. Don’t listen to those who tell it won’t help and you could send your message to Mars either way with exactly the same (none) results. Surprising, Martians can be very helpful when asked in proper way. Maybe that’s why “we’re looking at helpful people in business like they were small green extraterrestrials” (quotation taken from Szymon).

And yes, we’ve just received big help from our Martians.

Alternative Costs

- We can buy that control for 100 euro or we can develop it ourselves.

- How long it would take?

- A week or two.

- How do you think do we need the control in future implementations?

- So far we’ve always used different protocol. I guess this is one-time shot.

- OK, 100 euro is no money here. Let’s buy it,

- Hm... We have to wait for customer opening the tunnel anyway. Maybe we should spend the time to prepare the prototype. We’ll always have buying the control as a plan B if something goes wrong.

- Well... First, two weeks of any of those guys costs us more than a hundred. Second, think how much value we lose in things he won’t do during those two weeks. That’s not cheaper.

This time the situation was a no-brainer, but I think about others when someone forgets about alternative costs. Sure, you can spend months trying to win that deal investing a lot of time of both sales and technical staff and you’ll end up a runner up, which in case of bidding is a lose. Sure, you can take that project and engage the half of the team to finish barely on time rescuing the rest of not-so-impressive margin, maybe developers will have fun at least. Sure, you can spend long weeks developing your own implementation of that protocol, which was already done by other 561 companies although I wouldn’t bet it will either the best quality or the cheapest option.

Considering all those things as atoms, they can be easily justified. But remember – people engaged to those “projects” won’t do other work, which probably brings you some money. Your core projects can be jeopardized by doing a bunch of non-essential things. You’re going to take maintenance of all the new crap on your back with no repeatability asset making support engineers life a bit closer to hell than it used to be. These all are alternative costs. Things which can’t be easily shown in income and costs analysis, but are happening.

That’s why it’s often the best option to choose the “no go” option on the very beginning. If you have guts to do it of course.

Organization with Potential

There’s one thing which differentiates organizations with potential from those which are dead ends. It has nothing to do with the quality of the current system – it can be better or worse, doesn’t really matter. However, it has much to do with the way the company would change in the future.

The thing is:

The way the organization learns from its mistakes.

If your company/team/whatever is willing to take the lesson from mistakes which are made it’s worth to stick with it. Other way you’d end up with the same old shit you already have. Nothing special I guess.

Software Development and Project Management

During last weeks there was active discussion around under the flag “Agile project management is not about project management but about software development.” I think the thread was started by Glen Alleman. Among interesting comments you can find his follow-up on the subject and two cents from Bas de Baar.

To make the long story short: I agree with Glen and Bas that things usually covered with the name “Agile Project Management” are telling more about managing software development which is usually important but not the one and only part of project management. By the way we tend to see project management as an area exploited in IT only while it is widely used in others areas of our lives (building industry is a great example here) which haven’t much to deal with computers and all those software stuff.

Yes, project management is usually much wider process than software development and definitely more complex. But why the heck the discussion mentioned above was limited to agile methods? The difference is the same no matter which methodologies you use to develop your software and to deliver your projects. Hey, replace the word “agile” with “waterfall” or “iterative” and all the arguments still work. That doesn’t really matter if you’re agile or not, software development and project management will usually be two different things.