Truly a Project from Hell
Reddit resurfaced a 10-year old story about a project gone so terribly wrong that it sounds truly horrific. Just one anecdote from the article:
One developer was given the task of checking why right-clicking on the interface completely froze the application. After several days of careful examination and incredible amounts of patience, he found out that right-clicking worked fine, only that it took about 45 minutes for the context menu to popup. Menus were all dynamically generated from huge (static!) content every time you right-clicked the main window.
It's almost impossible to believe that such things exist.
There also a follow-up post with answers to common questions.
Some Thoughts on Manipulation
- Other person wants you to do something (which is not necessarily a bad thing).
- She wants to make you do it in a sort of "covert" way, which I would generally call a bad thing in professional environment.
When it comes to response to manipulation, all things being equal, I would have a conversation with a person saying something along the lines of "Hey, I've noticed that you try to trick me into something and don't like you doing that. If you need something from me, let's discuss, but don't try to trick me."
This kind of feedback serves two purposes: (a) letting other party know that you've noticed manipulation and don't like it (who does?); (b) showing a better way to do business with you. If a case is not helpless, this should help.
What do you do when somebody tries to manipulate you?
On Corporate Culture
Merlin Mann on corporate culture in "Back to Work" #17:
Living inside brick building full of lies.
Two types of answers
When I'm asked a question, my reply often is "Well, there are two answers to that question: a short one and a long one (or a simple and complex)..." And that is because there are indeed two types of answers to many questions. I would call them definitive and process oriented. For example, "how long will it take to complete this project?". The simple answer might be "we do not know", the complex answer will be "we do not know, but here is how we can control and manage schedule for our project and make it possible to make certain commitments on dates depending on your goals".
Another perspective on these answers is that one of them is like "here it is" and another one is "oh, here is how you get it".Remember that saying that professionals do not always know all the answers, but they always know how to find what they need.
The matter of fact is that process oriented answers are just as important as definitive replies. Of course, we should always starve to simplicity, but if there is no simple solution, we should not abandon looking for complex ones.
QUOTE: Heroics in the workplace
...People respond with heroic behavior. And when they act heroically, they stop improving. They just act heroically again, again, and again, and they stop learning.
David Anderson in interview for Software Engineering Radio.
Metrics that mean
We all know this law coined by Elia Goldratt:
Tell me how you’ll measure me, and I’ll tell you how I’ll behave.
This cause-consequence relationship between incentive and action is very important for managers. As with many other things this can be applied on different levels. Consider the difference of measuring someone by number of oranges sold versus number of happy customers returning to the store to buy oranges.
I came across a great example of metric taken to the next level in post £24m School Can't Get Its WiFi Working by Fraser Speirs:
In my school, we aim to lose no more than five teaching hours per school year to computer failure.
Do you see how this metric not only prompts "correct" behavior, but also sets the goal? Metrics like this are less prone to "local optimum" problem when person compromises on quality and results in some other areas make up for particular target, because they do not control action itself (like, selling oranges), but instead control ultimate outcome of the action (like, happy customers).
Are you and your team starve to get more happy customers or try to sell more oranges?
Change requests: In or Out
Many junior PMs think that Change Requests (in our company we call them Change Orders) always come to project team from the outer space, whenever the client or other stakeholders want to change something, like increase the scope or tighten the schedule. They think that CRs are there to protect the project team from changes coming outside of the project.
The thing is that CRs are not only about the scope. There are many more controlled project parameters, although the scope is probably the most notorious when it comes to changes. And whenever you need to change any of these parameters you need a Change Request:
- Scope
- Budget
- Schedule
- Specifications
- Quality (if you run projects better than others and really control quality)
When the customer wants to add something to the scope of the project, you need to issue a Change Request to adjust other parameters accordingly. When you need to change schedule, you issue a Change Request to communicate the change and get approval for it. So Change Requests are not only and not always incoming, they can and should be outgoing to communicate important things, which happen to the project.
Change Requests are meant to protect project stakeholders from silent changes in the project. As much as you want to be informed and be able to react appropriately to the additional work coming your way, the same way project customer wants to be informed and be able to do something on his end, if you decide that final delivery date needs to be moved.
Change Requests are means of communication and no wonder that not doing this part of communication properly can put your project at significant risk. Next time not only wait for CRs to come, but be sure to communicate the changes you initiate to other project stakeholders.
Also check out The Top 9 Reasons Why Projects Fail at The PM Podcast. Communication done right is 80% of successful project.
2 steps to more effective communication
I'm reading Garr Reynolds' "Prezentation Zen" and his points about efficiency of presentations, which can naturally be translated into efficiency of communication, resonated with my mind:
The presentation would have been greatly improved if the presenter had simply kept two questions in mind in preparing for the talk: What's my point? And why does it matter?
Now communication is more important than ever for me, since I work on-site with client and do not have luxury of face to face communication with my team. Should I be asked to generalize Garr's statement I would do it this way:
The communication would be greatly improved if the person speaking now would simply keep two questions in mind, when preparing to speak: Why my speech does matter? And what is my point?
I have heard dozens of perfectly made points, which unfortunately were not relevant and simply consumed the bandwidth. Alas bandwidth of communication is more limited than we usually think.
Keep that in mind and be an effective communicator.
Weekend listening: a couple of interesting podcasts
Now when my commute went from 10-20 mins to 30-40 mins in each direction I quickly burned the backlog of podcasts. I gave a try to some new and so far I like what I hear. Here they are:
What are some of your favorite podcasts?
Inducing a change
I'm currently working on site with client. The other day I had a conversation with one of the project managers and somehow we landed on a topic of inducing a change in organization. Especially, when the change needs to be supported by management and management is not very supportive, because the problem is not very high on the priority list. Depending on the actual environment and type of change involved here are two strategies that might work.
Get allies. Often times you and your fellow colleagues feel the pain, know the problem and see the solution, but management does not really understand what it is that you are trying to solve and therefore is reluctant to support you or allocate funds needed to implement change. What you can do it to get an ally, who shares your vision and is willing to take the problem and solution to the management with you. If two people show up with the same problem, it is easier to get attention and have manager spend time thinking about what you have to say. When you open a meeting you called to resolve this problem with "We've discussed this problem with such and such (and those people are in the room) and we are in agreement that solution would be..." it is much easier to get through manager's internal "why do I care?"
Propose to try. This is based on The Puppy Dog Close approach. Here is how Tim Ferris describes it in The 4-hour Workweek:
The Puppy Dog Close in sales is so named because it is based on the pet store sales approach: If someone likes a puppy but is hesitant to make the life-altering purchase, just offer to let them take the pup home and bring it back of they change their minds. Of course, the return seldom happens.
The Puppy Dog Close is invaluable whenever you face resistance to permanent changes. Get your foot in the door with a "let's just try it once" reversible trial.
There is psychological resistance to make perceivably big decisions without "proper" consideration, which, of course, never happens if the problem does not seem very important to management. By making the change temporary you lower the barrier for amount of consideration on the change. If the change will be for good, most likely no one will question the decision to make it. And, of course, if change for some reason does not bring the relief, you need to be the first to admit it and revert back to older procedures.
What do you do to induce a change in organization?
(Image by Dina Middin)