Tuesday, March 1, 2011

Being project-managed: survival guide

As programmers we are part of projects that are project-managed. Whatever that would mean, our payroll and job security often depend on projects' successes. If not, lucky you to work on badly managed, yet resorceful company. Go get a raise :)

For unlucky rest of us, I present this survival guide.

Duties of project manager

  • Deploying on time, high quality, working software
  • Fitting in budget constrains
  • Communicating clearly expectations and duties
  • Shielding programmers from client 'interference'
  • Establishing 'find the solution' and team working culture in face of trouble
  • Discovering and stopping 'just one more little change' stream - keeping scope under control
  • Taking the blame for failure or being a source of success

Types of project management

  1. Planning success. There is someone assigned to manage and he/she takes responsibility of leading the process from beginning to the great finish. Customers are happy and so is the internal team. Manager is exhausted, but drives home in Porsche.
  2. Planning failure
    • There is someone assigned to manage, but that person is not fully experiencing bad consequences of his/her mismanagement. For example: going over budged or finish date is not only his/hers problem. If manager cannot be fired after series of unsuccessful projects, or gets away with it because of unrelated (or unprofessional) factors, we have a problem..
    • The person assigned to manage has other duties in project. The more important are those duties, the bigger the failure.
    • Person in charge is paid for other things that could make up for project failure lack-of-bonus. Example of this would be never-negative bonus for both selling the project and for project implementation outcome. There is huge moral hazard here.
    • Someone is charged with management but no one is professionally evaluating his/her work.
    • A manager is a Holly Cow and knows that. Run away from project.
    • Your boss (or his boss.. or) is dependant on (family, love, sex, blackmail, friendship, drug dealer) the manager. This is really bad. Quit immediately if you discover such dependency or risk serious consequences.
    • No single person is doing all things described as PM duties. That actually can be played to make you a beneficent of process design failure. Think Wally from Dilbert series.

Why do I care?

Your work is evaluated in relation to the project. If project fails, you are part of failure. No raise, no respect. You should care about project management because projects needs to be managed to succeed, little beasts.

Persistence of management failures

If projects fail, how the company prevails? If you ask this, maybe you know too little of your company? Maybe you assumed wrong business model? What if your company earns 90% on hosting the solutions not on programming them? What if your clients also undergo moral hazard of not depending on project outcome? Example? A corporate manager in charge of huge budget that wants part of it for himself.
What if there are many projects in parallel and internal accounting process makes it impossible to evaluate financial outcome of managers work?
What if company makes so much money, that no one cares about projects you are part of?

Bad management sometimes exists also because of high pressure to use Project Management Methodologies (while forgetting WHY WOULD YOU USE THEM IN THE FIRST PLACE). If you use methodology just for a buzzword or have established a culture of 'I made this by the book, don't blame me' - your company might soon fail.

Bad management survival guide

  1. If bad management is common in your company, you'd probably benefit from quitting it unless you are paid very well. If you feel underpaid, there is no hope for raise unless you change jobs (because your work is judged in context to projects). Think twice however whether what you do, is worth more than you are paid - because that's the reason to have you employed. Do that every day - advice from Chad Fowler's 'Passionate programmer'.
  2. If you are offered some executive job, make sure that bad management won't affect you. If in doubt, assume that it does and refuse the offer. Team management is tedious no-fun, no-hacking job. Unless it would give you a huge raise (>25%), refuse. Why previous team leader quit? Got promoted or fired? Promoted to do what? What kind of person is he?
    Little raise + bad project management == frustrated programming team leader. Been there, done that.
  3. Do not ever try to fix company processes. Not only will you fail, but would seem like undermining your boss' position. That is a great "you're fired" opportunity. If you can't live with that, quit your job.
  4. If there are successful projects in your company, try to join those teams. Escape failure-generating platforms, managers, technologies. Be associated with winning or find solutions outside.
  5. Don't ever say it publicly in company what you think about bad project management. Suck it up, smile and do your job. Read Hackers and Painters by Paul Graham to understand why.
Any comments? :-)

Lectures

No comments:

Post a Comment