Change Your Estimates Now!

You’ve heard that probably.

“Your projects are usually late. Do something about that. We lose credibility in the eyes of our customers.”

Ouch.

“And another thing. Last schedules you’ve prepared are unacceptable. They should be cut at least by a half.”

And now you’re confused.

“Sure, feel free to cut deadlines by 50% and yes, this time we’ll deliver on time.”

Except of that’s not true.

To be honest I always feel uneasy when I have to deal with those kinds of situations. Yes, I understand so called business perspective. I actually can imagine that a couple of months of schedule can be unacceptable for a customer. I know that easier or more appropriate solution from the technical perspective can be rather not suitable business-wise. However at the end of the day you need to deliver. Hopefully something within scope, time and budget.

There is no easy answer how project manager can discuss those accusations. Several things can help however.

1. Make your estimates as reliable as you can. Create something what you believe can be achieved. It’ll be easier to discuss that later on.

2. Look for a compromise. A couple of man-months of development can be covered differently with different resources. You need different buffers for a newbie than for a veteran member of the team.

3. Remember about your environment. Estimates shouldn’t be done for veterans when you don’t have any in your team. If you have a number of other projects to do don’t consider there are none.

4. Be assertive. When something isn’t reasonable, point it. When something can’t be done, explain why your team isn’t capable of doing that. Describe what needs to be done if you are expected to achieve that goal. More experienced team? Some training maybe?

5. Talk about merits. Don’t start “it is so because I say so” type of discussion. It’s a dead-end. Think. Were past estimates good? Where you made mistakes? Why? Is that similar situation in any way?

6. Admit where you failed. Don’t try to play the hero because most likely you’re not. Most likely at least several of your estimates were wrong. Don’t try to hide that. Try to name reasons why it happened so. If it don’t help with the current discussion at least you look more credible with that.

And remember one thing: it isn’t a win-lose only scenario. You can end with win-win or lose-lose too. The former should be your goal.

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.

Ever-Changing Business Requirements

A typical time-span for projects we deliver here in Wind Mobile is about six months. That’s considered rather as an average size when talking about systems for mobile operators. However that’s definitely enough to see significant changes in this competitive business environment between the beginning and the end of the project.

Usually before we finish deployment we get a list of features which are to be ordered just after final acceptance. These are either new ideas which appeared during implementation or features forgotten during initial negotiations or things which appeared not very useful or usable during tests and need to be improved.

A great environment for agilists you would say.

Well, yes indeed. Except of I’m yet to see mobile operator which would agree on that methodology for a typical business project. Quite often it’s hard enough to break even a little step in implementation procedures, not to mention putting a whole thing upside down.

What option you have then?

• Go for agile. At least you can try. With typical business project it can be hard, but for projects which can be classified as R&D it’s easier. I’m lucky enough to work with that kind of approach with at least one of our customer. And for goals we put on our roadmap it works great. Unfortunately in most cases I can say you won’t be allowed to use agile approach with that kind of customers.

• Manage it. You work with one of old-fashioned ways. You have scope, you have schedule and here you go. Each time when new requirement appears you manage it – add to the list, decide whether to implement it or not. And once decision is made you take whatever it brings. Additional effort, retests, changes in other functionalities or... nothing. As far as you decide consciously you shouldn’t cry about it.

• Scope creep. That’s the previous option but left alone without any control. Sure, they will try to put in as much new features as possible. Sure, being a naysayer is unwise but so is the other end of the scale. If you enter to uncontrolled scope creep you won’t reach the goal in fair condition. It’s a difficult decision to set up the best point when you start to reject but a crucial one.

• Be a naysayer. Talking about naysayers... you can always say: “Hey, there’s an agreement and I can’t see even a word about the feature, so you better forget that until we see a signed purchase order.” You’d be surprised how often this approach is used. I’m not sure which scenario is worse – this one or scope creep. When you have a standard answer for every question, most of the time this answer won’t be any good.

It’s always worth to look for the most reasonable way of working with changing requirements. Agile brings very good answer for that, unfortunately its implementation quite often isn’t feasible (that’s subject for another post by the way). But each process which involves a common sense and a bit of analysis to decide individually what to do with new or changed requirement should work well.

I’m curious what your approach in that area is.

Who Is On the Other Side?

Our team was reinforced lately by an experienced project manager. He worked in his previous company with one of our clients. I’d add that our client works in formalized environment where compliance with procedures is (usually) very important, which should limit freedom in project management. The interesting thing is we can confront our experience.

If I had to give one general conclusion I would say that the way the project is run is highly dependent on people, especially project managers, on client side.

Project manager’s strengths and weaknesses have great impact on the whole project. With a great organizer you won’t need to ping them for each delivery you’ve agreed. With a PM with wide technical knowledge most issues can be resolved in small group and there’s no need to check every little thing with specialists. Person who work in the organization for years will know each shortcut and backdoor within procedures and will be able to exploit them. Overloaded project manager won’t push a project very hard as he’s, well, overloaded. Guy who’s not liked much among colleagues will find hard to organize help whenever needed.

Project we compared were run completely different. While general procedures which applied were exactly the same project managers had different profiles. By the way, I guess if we had other guy on the other side we would finish our project later.

On a side note I’m sure the same rule applies when you’re a client and you look at vendor’s project manager.

That’s why it’s so important to know who is on the other side. You want it or not you’ll have to adjust to people you work with. You’ll need to exploit their strengths and mitigate impact of their weaknesses. And I’ve seen enough different types of PMs to believe that depending on people on the other side project implementation can look dramatically different.

Who is on your other side?

Don’t Be an Orthodox

Lately I had a chance to observe a discussion about using agile methods. The problem which started the discussion was how to apply agile when we work in a fixed budged scenario. It wasn’t much later when I heard arguments like:

You can’t estimate effort needed to complete something which is done during nth iteration. It’s a fiction. Does client want a fiction? I don’t think so. You can explain it.

Then another great idea followed:

When the client changes requirements after they were approved we change the price. You shouldn’t be tricked. If you are it’s better to find other clients.

Nice. So simple. Your methodology tells you to work exactly that way so you do it. And when your client doesn’t accept that, sorry, you just leave. They aren’t worth to waste your time.

Oh, on the side note I think it’s time to declare which side I’m with. Neither against nor for agile. I just try to find the most reasonable way out in every situation.

Coming back to the discussion. Yes, the clients quite often want “the fiction.” They want to spend specified amount of money for specified amount of features. A surprise? It shouldn’t be. At least as far as you deal with people who doesn’t spend their own money.

And if your answer to scope creep is to leave the customer I wouldn’t invest my money in your company. Yes it can work that way and it can even bring money, but telling the customer they’re wrong isn’t the best strategy I’ve ever seen. Neither is rejecting to adjust your approach to the environment you work in.

Don’t be an orthodox. When something doesn’t suit your vision of software development and project management it doesn’t automatically mean it’s wrong. If you believe in your methodology go, convince the customer to use it. But don’t cry when they say they want it other way. They pay, they decide.

We are usually closed in our small niches. We usually don’t see all sorts of choices around. And we believe we know better. Until we see we don’t. For me the eye opener was moving to another company with different team, different processes, different products, different clients, different everything. And now I can’t say that one or another approach is better. They’re just different.

Make PM Work a Bit Easier

Everyday work of project manager is, well, interesting. You talk with clients. You manage your team and organize their work. You work on schedules. You prepare reports. You deal with different issues. You supervise everything. You prepare a thousand of different things. You create hundreds of documents. Phone calls, emails, instant messengers and meetings. Quite diverse job. And quite complex.

It requires specific type of people, that’s for sure. But you can do more. You can simplify a bit project manager’s work. How? Actually that’s the question for you.

Range of tasks done by PMs differs. There are companies where PM is one man army and is responsible for almost everything, sometimes even getting a deal. Unfortunately the more tasks are assigned to a project manager the less time he has to spend on the most important thing – managing a project.

If you can safely take off his head anything with no significant impact on business do it. Maybe budgeting can be done by someone else? Possibly presales team can take a bit more of work with preparing offers. Definitely someone should isolate PM from office wars and let him do his job. Nice idea is not to force project manager to think if he has enough office space for the team.

Sometimes when I talk with fellow PMs I’m surprised how many strange things they have to do. Typically these are things which PM will rather easily deal with although I can hardly say it’s typical PM job. Unfortunately it takes the time. First it takes time to do those things and second it takes time to switch threads. OK, PM will often switch threads anyway and unlike developer it’s rather normal situation but still, the less switching the better.

The recipe for each organization can be different. If no one else can prepare a budget for a project or there’s no sales force to work on new deals you can’t just cut out those tasks. But I guess there are things you could easily switch to more appropriate people. Just think about it.

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.

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.

Good Post Mortem

You have just done a post mortem after a project. How do think, was it good? Or it went rather poorly?

If it was a bad post mortem you can probably feel that. People didn’t share their thoughts about a project or they did it just to have you off their back. You received a bunch of generalities and nothing surprised you on the whole list. Yes, you’d know if it was bad.

How do you know if it was good? The answer is: 5 minutes after finishing post mortem you just can’t know. Most of people could have made their homework adding their thoughts what had been good, what had been bad and should be improved in future. There could have been a discussion during presentation of the list on a team meeting. And you still can’t know.

It will be a good post mortem if you take its results and implement some improvements. When lessons learned are actually learned. Unfortunately sometimes a great beginning – whole work with thinking over whole project – is thrown into the trash, because no one ever looks at the post mortem results and does anything to improve things. That’s why you can judge post mortems after at least few months.

We’ve just started a great post mortem after a big project. First step has been done, as the outcome conclusions point quite lot areas to improve. We’ll see if we can change it to a good post mortem.

When Crisis Comes

How do you act when a crisis comes? Does it motivates you to find unused resources of energy and creativity or rather overwhelms and tires you? Answer yourself honestly. You are not on the interview.

How do your people act when a crisis comes? Who performs well and who don’t deal well with pressure? Think about that before you need to choose those who would help you in a difficult situation.

Ask people how they deal with stressful situations and virtually everyone will tell you that’s not a problem for him. Look at people working under pressure and at least half of them won’t perform very well. A differentiator here is a mixture of several traits including creativity, ambition, general attitude (pessimist/optimist) and engagement.

I don’t say everyone should have the mixture or not being that kind of person is bad. No. But there are roles out there which are much easier to fulfill when you deal well with crisis. Project manager, support engineer, fire fighter, marine... Oops, wrong branches.

Although some of us are more predisposed to deal with stress than others it can be learned to a certain level by anyone. And even when you’re not willing to learn that there are a bunch of positions where it isn’t needed as much. Most of development or quality assurance roles (although not all them) to take the most obvious ones.

When a crisis comes you look for people who will perform well in the situation. When a crisis comes it’s better to know whether you can count on each person in your team. Including yourself. Answering the questions stated at the beginning isn’t a waste of time.

When Project Is Finished

What did you do when your last project came to the (hopefully successful) end?

Did you write an email to the team saying how crucial had been their effort to complete the project?
Did you thank your team?
Did you bring a bottle of champagne to symbolically celebrate a success?
Did you praise the team to your bosses?
Did you invite the team to a party to reward their effort?

If not, well, you should seriously ask yourself why. Probably something is wrong either with you or with your team.

Dealing with Ass-Covering Project Management

I’ve written recently about ass-covering project management. That’s all about getting a proof something actually was agreed. This isn’t always very easy. How to act when you end up in that situation?

1. Follow-up. In that kind of environment you won’t get much information on paper or in emails. Most of communication will be done by phone. Why? No proof. No stress. After important (from your point of view) phone call just take a while to write a follow-up email: “As we agreed during our phone call...” You will act as you just want to confirm or particularize agreed details.

2. Calm down. You’ll get messages which will make you angry. Unfair. Untrue. You’ll rush to answer them angrily. Wait. Calm down. When you’re angry you’ll probably write something you’ll regret. My trick here is to write the response instantly, but instead of sending the message I read it and then cancel it. Then I write once more. In extreme situations I use a third iteration.

3. Call a bluff. In the atmosphere of trying to find a hook for other side you’ll often face the situation when someone implies you things you haven’t said or done. Call a bluff then. Don’t treat it as a normal situation but state the situation never happened or it’s just untrue. As far as the right is on your side you’ll rarely hear accusations once more.

4. Be active. Treat this as a game. You not only have to defend you actions but you can also attack opponent. Think for a while if the other side owes you something. If yes, just write a nice email: “As you haven’t completed your task we can’t continue the project in that area, which invites a delay...” You’d be surprised how that can improve other side’s engagement in completing their job.

5. Escalate. Use wisely organization structure of both companies (yours and client’s). Depending on the issue sometimes letting higher ranks know can help much. Especially when things are going too far for you. There’s no glory for bringing conflicts to the project when you overreact. Here I won’t give you an easy tip when to escalate, as there isn’t any. You have to try to judge the situation and go for what you feel. Just remember that overuse of escalation can result in adding you to decision-makers’ ignore list.

A little disclaimer: I do not recommend pushing your project into ass-covering mode. Unfortunately that’s rarely your decision and rarely can you change it. Just remember you’re not defenseless.

Ass-covering Project Management

You can define project management in many ways. I’d say the definition will differ depending on the project you actually run, its size, the customer on the far end etc. And definitely there are projects which could be at least partially defined as getting ass-covers.

It will happen usually when (either one):

• Client constantly changes the scope of the project.

• There is significant delay which can’t be clearly ascribed to one of sides.

• Project teams don’t like each other.

• Choosing a vendor was a political decision.

Sure, that mode of running a project isn’t a favorite one for most people, but it’s rarely you who is decision-maker. Usually you just follow whatever rules apply. If you’re unfortunate to work in ass-covering mode you better go and get some of those.

Otherwise you’ll end adding a number of features which weren’t planned. Or reconfiguring the environment multiple times instead of doing it once. Or being blamed for issues you weren’t responsible for. Or paying forfeits which aren’t quite fair. Nothing pleasant here.

On the other hand when you have to run a project that way, which I really recommend to avoid whenever possible, it can be quite a joy to have your ass-cover when you really need one.

Clue of Project Management

Project management is often reduced to discussion about methodologies used to help with the process. We are agile. You are formal. And they are not only formal but also waterfall, ouch. OK, that’s a part of project management, quite an important one, but that’s not the clue.

Show me whichever methodology you think is the best, I’ll give you a bunch of good people and the project still can fail. Why? Because you can live without a methodology to deal with projects and can still do your job (although no one says it will be easy). You’d be surprised how many companies still employs that old gung-ho technique called sometimes “Halleluiah and forward!” And they can be successful.

Why is it so? Because the methodology itself isn’t a clue of project management. If I had to look for the core of managing projects I’d go for a combination of few things.

1. Communication. First and the most important one. As far as your project team sucks in communicating with each other and with the customer you’re doomed. You’ll lose time, money and people’s energy doing unimportant things or not doing important things or hitting the wall hard with your heads. Developer will state the code works because he misunderstood bug submitted by customer. Service engineer will reconfigure servers as it was stated in old out-of-date specification. PM will set wrong priorities as she hasn’t verified customer’s priorities. Poor communication is usually enough to bring any project into serious problems.

2. Understanding of customer’s goals. And when I say “customer” I don’t mean a company, but personally every single person you work with. PM, tester, technical director, marketing manager, everyone. That’s tricky part because usually when you work with a new customer you don’t know people you’ll interact with. Later, when their attitude will be changing you’ll be guessing what the heck is happening. And you won’t know as far as you don’t understand people’s goals. Especially in a big organization they can be quite different than you’d expect and quite different than company’s goals.

3. Focus of the project team. When project team doesn’t know what are they exactly doing (on the high level) and why you’ll always face a series of small issues which shouldn’t happen. Someone won’t do high-priority task. Developers will be switching a bug between them saying it’s not in their code. Fixes will ruin other functionalities. OK, none of them can be the only reason of failure, but when combined they’re really hazardous. A number of distractions also influences the focus of the team.

Nothing here tightly connected with any of project management methodologies. Sure, personally I’d add e.g. flexibility to the list, but on the other hand I’ve seen at least several those hard-core formalized projects which ended up as successes, so you can live without that.

If I had to summarize it shortly – clue of project management is to know what should be done and for whom. Unfortunately it only sounds easy.

Project Management Methodology Trap

You’re a project manager or a developer or a support engineer. Doesn’t really matter. You use some project management methodology. Agile, iterative, formal, whatever. Doesn’t really matter. When a serious issue appears on the horizon, your methodology tells you more-less what the person in your position should do. Reject any external change until current sprint is finished, choose the development cycle which the feature will be added in, start formal change request process or whatever.

That’s the default path. You can follow the path and probably no one would blame you. Unfortunately there’s a trap in that approach. There’s no procedure which can tell you how to act well in every possible situation. All you can find is what to do in typical situations. Unpredictable things happen much more often than once in a lifetime. Actually you can predict that unpredictable will happen and it will happen quite often. In these situations default answer shouldn’t be default any more.

We had a subcontractor who failed to fulfill their commitments within the project. They didn’t really care about potential consequences because they didn’t intend to continue cooperation in the long run, as it appeared later. On the other hand our deal with the customer was crucial for us.

The default answer was: squeeze the subcontractor as hard as possible, while trying to calm the client down. We would probably take another 3 or 4 months of painful cooperation and finish the project anyway, as it already was on quite advanced stage. We did something else. We overtook the part of the unfinished development work from the subcontractor (which required ad-hoc team reorganization) and completed the project in less than a month. If we had to justify our decision we’d be talking about vague criteria like belief our team would make it or feeling it was a right choice. Try to find them as decision-making factors in any project management methodology.

Another example. After a couple of months of joint development with one of our clients we heard several um... let’s call them advices. The client expected extremely flexible approach up to possible changes requirements on any stage of the project with the instant reaction (implementation) on our side.

The default answer was: we follow this or that methodology and it tells you we have to formally manage changes. That mean you have to wait until we’ll be finished with current iteration/sprint/whatever until we’ll do that. Or better: hello, there’s not a word about that in analysis. Can’t do, sorry. On the other hand we used common sense which told us the joint development program is very valuable for us and as far as we’d set up our thinking on paths expected by the client it can go quite smoothly and both sides could be happy. So without much thinking we went for that so-called flexi project management (which has more to do with “flexi” than with “project management”). After all the both sides are happy I guess.

When you switch off common sense and constant thinking how issues can be solved other way than default one you fall into the trap. Standard answers are good for standard questions which are surely far more than 90% of project management work. But for the remaining few percents you need to act different. If you always look for an answer in procedures you got caught. Sorry.

Yes, unconventional actions are much easier to implement in small organizations where everything is less formalized. It is of course possible (yet rare) in big companies too, although in that case it is usually a function of people accountability, which is a function of company culture.

New Features in Wrike

Some time ago I received a message from Daria from Wrike. They’ve fixed one on major issues I’ve pointed in my Wrike review. When you use email integration long threads won’t multiply tasks any more. It is called intelligent reply function. When another email is created in the thread (using reply all function which keeps wrike@wrike.com address on the recipient list) a description of the task will be updated instead of duplicating the task.

Unfortunately another issue appeared. After a couple of answers with standard company footers and multi-line signatures description is cluttered and you don’t clearly see where the useful information is. There should be either text formatting kept form original email or some kind of intelligent and configurable mechanism which allows cutting off needless trash from emails automatically. Or better, both of them.

It's quite typical example of situation when you can’t say that adding a feature invited a bug, but users using the new feature have to face some new problems. When you design new functions, you should always think how users will interact with the application. Think about the whole process user executes, not only about the part which is directly influenced by the new feature.