Posts Tagged “project management”

Do you think you are a rockstar project manager? Can you roll out an agile process and leap the tangle of legacy waterfall hurdles without breaking a sweat? Can you walk unaided from a fight club thronged with hackers, cowboy coders, support junkies and alpha heroes? Want to prove it?

I’ve got the acid test for you.

Identify a small product that you have always wanted to build. Commission something that you could use on the job or at home. It needs to be something that requires more than just you to complete. It must require a budget, paid help, realizable value, clear goals, and a plan. In other words, scope and fund your own project.

Yes. You fund the project with your own money. That’s what makes this an acid test.

For me, for example, this something is to rebuild and productize a web-application that has become a critical part of managing the rental properties my wife and I own. We have used two different prototypes over the last two years and I firmly believe this product captures a soon-to-be-ubiquitous element of property management. So I am taking the leap.

This PM acid test assesses whether you have the skill to contemplate and manage everything about your small project (and the product on which it is based). Either directly or via delegation you will need to:

  • Define your own requirements and break them into plannable features.
  • Identify a MVP (minimal viable product) and keep the project aligned to that vision.
  • Find and contract with the professionals who will complete the work.
  • Forecast and manage the development schedule.
  • Identify the technologies to use and the deployment environment.
  • Vet archiitecrure and design decisions.
  • Review all completed deliverables from a functional and technical perspectives.
  • Balance new features versus technical debt.
  • Do anything else a project manager, product manager, product owner, stakeholder or sponsor would do or delegate.

Of course you can get help on any or all of these activities. You can hire an architect to make decisions and review code. You can hire a QA professional to write scripts and run tests. But you still need to acclimate these professionals to your product and vision. And any additional hands will cut into your budget.

Even when delegating you still need to preform an informed review of all significant work products. Delegation without review is an elephant trap.

The only certainty around this acid test is that something will go badly. If you hire four contractors at least one will be a dud – you’ll pay someone to clean up that mess. Your own conception (and delivered specs) of the system will never be free of potholes – someone will need to go back and patch those, or dig up the road and start over. And your vision of the product will never be communicated so clearly as to avoid every misstep – that’s more rework still.

You will need to be on top of everything. Or you can sit back and watch Team Burn Rate blow half your budget in two weeks. Whenever anything goes wrong it will be your fault. You did not give clear requirements. You hired the wrong person. You changed your mind. You let one decision sit too long and made another decision too early. You let a technical issue sit unaddressed as it smoldered its way through your release timeline.

Can you complete a releasable version of your own, personably-funded product before you cut off the money supply because you can’t lose any more? That’s why it is an acid test.

Comments No Comments »

For some this is a heinous anti-practice. For others it’s standard operating procedure. Either way it’s the fast track to project ruin.

Plan and Ignore is the practice of quickly drafting a project plan (typically to satisfy an external demand; typically in Microsoft Project) then tossing the plan and never looking back. This happens for any number of reasons. Some people don’t know how to plan. Some people don’t know how to track. Some simply don’t want to invest the time to do either activity correctly.

Plan and Ignore should never be confused with even the simplest forms of agile planning. Even the lightest-weight planning (such as a product backlog, t-shirt size estimation, and a burndown chart) can keep a team free of this anti-practice trick-bag.

The fundamental problem with Plan and Ignore is that no one actually knows the status of the project. Behind? Ahead? Safely on track? Likely no two people on the project team will give you the same answer.

And when your team has no consensus on its status all manner of bad mojo can result.

If you are actually behind, the people who don’t see this will likely be busy cathedral-building and apple-polishing instead of developing the much-needed ladder that the team will use to climb out of its current hole.

Furthermore, lack of agreement on a team typically raises the attention of management, especially when that lack of agreement is around status. But management often does not know how to be helpful in situations like this. They’ll demand to see status against the current plan, go hulk-mad when they discover that there is no current plan, demand a new plan be drafted, and waste yet more precious time prying tracking data from team members who are frantically trying to not fall further behind.

Finally, if management doesn’t cop on to the lack of consensus then the team will know they are behind only when they reach a consensus on the matter. Typically this happens one week before a major milestone, at which time the team recognizes the obvious – that it is no less than four weeks behind. And that’s when the fit will really hit the shan.

Comments No Comments »

Ostensibly originating in Rebel Without a Cause the game of chicken entails a test of courage between two or more individuals. Each participant is seated in a speeding vehicle (50s sports car, farm tractor, failing project schedule, etc.) racing toward a certain demise (cliff, head-on collision, delivery failure). The chicken is the participant who abandons his vehicle (or comes clean with management) first. The chicken either loses the contrived, Hollywood-scripted contest or gets reamed by management. The participant who bails from his vehicle last (or avoids having to come clean with management) either gets the girl or is rewarded with another project to go and wreck. In rare cases, I suppose, he might get both.

And therein lies the true and long-term damage of this particular anti-practice. In Hollywood movies chicken is a one-time contest. For project management, schedule chicken is an iterative game, where the most dishonest and deceptive participant wins and is encouraged to hone his destructive behavior so as to win again in the next round. In management environments that foster schedule chicken, transparency and honesty are inadvertently discouraged and even punished.

Furthermore, we cannot ignore the project teams strapped to the backs of these vehicles as they speed toward the inevitable. Even though the dueling PMs have a terrible tendency to do just that.

I have met project managers who are consistent victors at schedule chicken. They hop from one project wreck to the next, while the incurious executives eye them as can-do rockstars. Sometimes the project teams don’t know what hit them. Sometimes they do. But even then, no one’s really listening to the opinions of the bit players.

I’ve found only one effective defense against hard-core schedule chicken. Don’t play the game. Establish my own rules before the contest has a chance to start. Go über-transparent from day one. Let management know what’s really going down on the project, both good and bad. And keep management up-to-date on a weekly schedule. The key to disclosing the bad is that I must always have and present a strategy to explain how I am going to correct for it.

This über-transparency keeps me from ever heading toward the cliff. It guides me and my teams to correct issues and risks as they arise, and the project timelines and project teams are better for it. Further, über-transparency can send management looking for the same wealth of information from other project managers, making it more difficult for them to get a running start at the cliff.

Even if other PMs continue to play schedule chicken, by not playing my project teams and I cannot lose.

Comments No Comments »