The guys at Surity, who are running our week long PM workshop have some excellent skills and resources when it comes to project mangement.
(don't let their appalling website fool you. It's true - the blink tag lives!)
I've learned a whole bunch of really valuable stuff, and it's made me re-consider what I think the really important elements in project management are. So, I'm going to blat them out here.
Incoming!
Build a Great Team
I still think that there is more to be gained from optimizing the team rather than the process. That idea intrigues me - maybe because you can't fill in a template for a great team...most of the focus at this workshop has been around contractors and software deployment management - where you don't get to pick the team, and you have to deal with whoever the customer sends. In an ISV software project , you can choose the team that you want to run a project. It sounds totally obvious, but If you want great software, this is the single most important project element there is. A great team can transcend any process flaws.
Bad news is always best early
Unlike a fine wine, bad news gets worse with age. People like everything to be on track, and they don't like to admit that they might have screwed up. So when things go bad, people often tend to solve the problem by pretending that everything is fine. This is the worst possible outcome. If things are bad, any team member should be yelling and carrying on as soon as they know it. And on a good team, they're just as dissapointed as anyone else, but they know that their team won't persecute them for it.
Slipping is Not Bad
Slips happen - schedules are always future gazing things, and humans are only good at predicting the future in the short term. For instance, I bet you can pretty accurately predict the next three minutes with about a hundred percent accuracy. But once you try to predict a week, it get's fuzzy, and if I ask you to predict the next six months, you'll have no chance at all.
So, a slip is when something you didn't know, becomes known. While this is dissapointing because the project is under more pressure, it's also good, becuase we know that stuff now. We can get a more accurate idea of what this evil task looks like, and ammend accordingly. Like Jim McCarthy says - a slip should be a net positive.
Define, Define Define
Really, this is all project management is. Keep defining everything you can get your hands on, and get those definitons into the teams collective brain. Define Risks, Define Responsibilities,Roles, Tasks, Issues,Benefits, Functionality,Milestones, Budgets, etc. Nearly all the scary problems in project management come from the areas that haven't been properly defined. And you can't just stop defining once the design is done - you have to keep defining everything you can get your hands on right up until ship day. Really, it's a very definey job.
(don't let their appalling website fool you. It's true - the blink tag lives!)
I've learned a whole bunch of really valuable stuff, and it's made me re-consider what I think the really important elements in project management are. So, I'm going to blat them out here.
Incoming!
Build a Great Team
I still think that there is more to be gained from optimizing the team rather than the process. That idea intrigues me - maybe because you can't fill in a template for a great team...most of the focus at this workshop has been around contractors and software deployment management - where you don't get to pick the team, and you have to deal with whoever the customer sends. In an ISV software project , you can choose the team that you want to run a project. It sounds totally obvious, but If you want great software, this is the single most important project element there is. A great team can transcend any process flaws.
Bad news is always best early
Unlike a fine wine, bad news gets worse with age. People like everything to be on track, and they don't like to admit that they might have screwed up. So when things go bad, people often tend to solve the problem by pretending that everything is fine. This is the worst possible outcome. If things are bad, any team member should be yelling and carrying on as soon as they know it. And on a good team, they're just as dissapointed as anyone else, but they know that their team won't persecute them for it.
Slipping is Not Bad
Slips happen - schedules are always future gazing things, and humans are only good at predicting the future in the short term. For instance, I bet you can pretty accurately predict the next three minutes with about a hundred percent accuracy. But once you try to predict a week, it get's fuzzy, and if I ask you to predict the next six months, you'll have no chance at all.
So, a slip is when something you didn't know, becomes known. While this is dissapointing because the project is under more pressure, it's also good, becuase we know that stuff now. We can get a more accurate idea of what this evil task looks like, and ammend accordingly. Like Jim McCarthy says - a slip should be a net positive.
Define, Define Define
Really, this is all project management is. Keep defining everything you can get your hands on, and get those definitons into the teams collective brain. Define Risks, Define Responsibilities,Roles, Tasks, Issues,Benefits, Functionality,Milestones, Budgets, etc. Nearly all the scary problems in project management come from the areas that haven't been properly defined. And you can't just stop defining once the design is done - you have to keep defining everything you can get your hands on right up until ship day. Really, it's a very definey job.
Comments
Post a Comment