One of the most important things in managing your project is to have a clear vision on what is it you want to deliver. Of course we all want to deliver maximum features with very low defect ratios, within 6 months time frame. I have news for you this is usually not possible. Those are interdependent and usually investing in one of the constraints costs you neglecting another. You will be making priority decisions throughout the project, so why not to get clear on what are them at the beginning. That would also give your team a clarity on what is important to the project and how to act when they would have to make priority decision themselves. So keep everybody in sync by providing priorities in advance.
As it always come to comparing two (sometimes more) project characteristics when you are supposed to make a decision I would recommend to write down an order of priority list which has the most important characteristic on top and then descend to less important characteristics.
So for example if you are targeting visionaries with new innovative project you know that you have to generate a specific minimal features set, release it as soon as possible, and think about quality later. You can reflect it in your list. That means that if your defect levels are high but you still don't have complete feature set you will devote your time to implementing features and not improving quality. Second important thing is to define what are the must-haves from the list - things which have to be accomplished for the project to be successful.
Now, make sure you are on the same page with your sponsors and potential customers as otherwise you are heading for disaster. You must be sure that list reflects priorities of people who fund the project. Talk to the sponsors and get them to choose what's the most important by simply asking them. If they don't want to choose as they want 'perfect quality, full feature set, 6 months, 4 people team' ask questions which will mimic decision you will have to make: "let's say it's a month and we still don't have full feature set and quality is low, shall we focus on quality or on features? Or maybe delay the release?". Do whatever you can to get it out from your sponsor. If you can't make the decision yourself (in advance) and get sponsor to agree, sign off on it. Without that project will be dead on arrival - overconstrained projects rarely are harder to deliver they usually are impossible to deliver. Unless you are Chuck Norris of course.
Showing posts with label project management. Show all posts
Showing posts with label project management. Show all posts
Tuesday, January 6, 2009
Saturday, January 3, 2009
Tuesday, November 25, 2008
Prima donna - 50 ways to kill your project
While we are talking about developers - there is one group, which 'deserves' a separate entry. These are software prima donnas - boys and girls who have one major goal - to look smarter than the others. Much smarter that is.
As you can imagine with such agenda there is not much good they can contribute to the project. It was kind of obvious to me since my day one. But I had no idea about how much harm to the project a single prima donna could do...
Let's look at them for a moment - it's easy to spot them – get the whole team in one room and talk to them about anything - if you see a person with silent disapproval on the face - this is your prima donna working hard for her throne. What always amazed me was the fact that the subject of the talk was irrelevant, the person talking was irrelevant - prima donna had always this unhappy 'I would do it much better' face.
Now, don't get me wrong - it's not like every project has them - in my whole professional life I worked closer with only three of them.
They are rare, but they are deadly.
Their number one goal is asserting their superiority. They have all kinds of power tricks in their arsenal: misleading, information hiding, gossiping, marginalizing others’ achievements, coloring up own achievement, over complicating things to arrive as a great savior of the day afterwards, asking questions without good answers, refocusing toward my areas of expertise, implying others' lack of competence, learning some very detailed part of knowledge and dragging it out whenever possible, you name it.
If they manage to achieve that they try to find followers - they are a building opposition business now. First of all they spread 'being unhappy' atmosphere. After all they need to be in opposition to something - the existing order of things. That means that current state of affairs has to be a bad one. If it isn't it has to be made one. And as we all know, unhappiness spreads easily so soon enough you will have an unhappy crowd instead of the team. And then it's usually too late to save a project.
Now, is it possible to fight the 'sneaky prima donna sabotage'? Of course it is - all you have to do is to show that the prima donna superiority is a fabricated one. Provide enough visibility on prima donna work effects (software creation related) and two things will happen: first of all everybody in the team will see that there is nothing special in prima donna performance, this is just as normal person as we all are; and secondly that would also force prima donna to focus on what he should be focusing on - software development. That should put prima donna covert operation into sleep (until better times come).
Or if you want a long-term solution - as soon you spot prima donna operating just split with her. You have my word - she will find another job and will be as unhappy there as she is with you. That's what prima donnas do.
As you can imagine with such agenda there is not much good they can contribute to the project. It was kind of obvious to me since my day one. But I had no idea about how much harm to the project a single prima donna could do...
Let's look at them for a moment - it's easy to spot them – get the whole team in one room and talk to them about anything - if you see a person with silent disapproval on the face - this is your prima donna working hard for her throne. What always amazed me was the fact that the subject of the talk was irrelevant, the person talking was irrelevant - prima donna had always this unhappy 'I would do it much better' face.
Now, don't get me wrong - it's not like every project has them - in my whole professional life I worked closer with only three of them.
They are rare, but they are deadly.
Their number one goal is asserting their superiority. They have all kinds of power tricks in their arsenal: misleading, information hiding, gossiping, marginalizing others’ achievements, coloring up own achievement, over complicating things to arrive as a great savior of the day afterwards, asking questions without good answers, refocusing toward my areas of expertise, implying others' lack of competence, learning some very detailed part of knowledge and dragging it out whenever possible, you name it.
If they manage to achieve that they try to find followers - they are a building opposition business now. First of all they spread 'being unhappy' atmosphere. After all they need to be in opposition to something - the existing order of things. That means that current state of affairs has to be a bad one. If it isn't it has to be made one. And as we all know, unhappiness spreads easily so soon enough you will have an unhappy crowd instead of the team. And then it's usually too late to save a project.
Now, is it possible to fight the 'sneaky prima donna sabotage'? Of course it is - all you have to do is to show that the prima donna superiority is a fabricated one. Provide enough visibility on prima donna work effects (software creation related) and two things will happen: first of all everybody in the team will see that there is nothing special in prima donna performance, this is just as normal person as we all are; and secondly that would also force prima donna to focus on what he should be focusing on - software development. That should put prima donna covert operation into sleep (until better times come).
Or if you want a long-term solution - as soon you spot prima donna operating just split with her. You have my word - she will find another job and will be as unhappy there as she is with you. That's what prima donnas do.
Monday, November 24, 2008
In search for developers - curious craftsmen wanted!
We looked at what a good manager is supposed to be about. Let's now try to figure out what makes developers write better quality code. Things like skills and brilliance may certainly help. But are those the core components? I don't think so.
If I was to choose perfect features of my team member I would go with curiosity, engagement, openness and thoroughness in no particular order (or maybe in alphabetical). All right - I can add that some programming experience would be a plus as well.
Let's start with openness - no software developer is an island, thus communication is everything in software business. I talked about it already but I can't emphasize it enough. Unless you don't need extensible maintainable software, its' creators have to communicate with their peers and the rest of external world. So they do have to have two following skills: being able to talk to others (and actually practicing it) and being likeable enough to be talked to. I'm not saying that they should be party stars or anything like that. Nerds with working I/O would do.
Now, what I found is that creating something of high value and high quality was always going in pair with having fun working on it (no matter whether I was a developer, architect or manager). I think that basically goes with the feeling that you are doing something right. Moreover, in these projects I had people who no matter what they were doing, they were always putting their 100% in it. It was somehow easy to get them engaged. At some point I figured out that they had engagement ingrained in them. And believe me you want to work with such people. People who don't give a damn, who are 'just earning money' are not fun to work with. They are inclined to take shortcuts, think short term and to look at you with 'what this has to do with me' face in the time of crisis. If you can - work with people who care about what they are doing.
As I mentioned earlier building up quality is all about incremental improvements, innovations which make your code better and better. And to innovate you have to stay up to date, learn and try new things. Think about your current quality as the status quo, comfort zone your developers live in. If you want them to get out of this cave they need to be curious enough to take action which would push them out. Given that they are wondering enough to see shadows and hear echoes in the first place. No progress without questioning, in short.
And finally thoroughness - this is the difficult one - most of the folks go into this business because of high payoffs for creative actions - you build up several routines and you are already running something which paints beautiful outputs to your screen, you change a bit of it and the outcomes are completely different and even better adjusted to what you wanted to get. This is what we all are for in this business. Unfortunately, if we want to make something more out of it than a creator's toy - after we have the prototype which works with input of our choice, we need to put ten times more work to make it work with all the inputs in all situations - and this is not so much fun any more. Ratio is different based on how you modeled domain in the first place, but still creative piece is always far shorter than the process of handling non-standard cases afterwards. To make things worse we know how to get next adrenaline fix - we just need to move on to creating next piece. It requires a lot of discipline to finish it up - I've been there - it took me many years to develop thoroughness and ingrain it into my character and I still have slips from time to time. Fortunately being able to do the task completely offers also good chemistry strike through your body and additionally good managers will be looking for you everywhere.
To sum this up - features commonly searched for like skills and creativity are for sure important, but at least my experience says that some character traits (which by the way would make you stand out in anything you put your hands to) are far more important than that.
If I was to choose perfect features of my team member I would go with curiosity, engagement, openness and thoroughness in no particular order (or maybe in alphabetical). All right - I can add that some programming experience would be a plus as well.
Let's start with openness - no software developer is an island, thus communication is everything in software business. I talked about it already but I can't emphasize it enough. Unless you don't need extensible maintainable software, its' creators have to communicate with their peers and the rest of external world. So they do have to have two following skills: being able to talk to others (and actually practicing it) and being likeable enough to be talked to. I'm not saying that they should be party stars or anything like that. Nerds with working I/O would do.
Now, what I found is that creating something of high value and high quality was always going in pair with having fun working on it (no matter whether I was a developer, architect or manager). I think that basically goes with the feeling that you are doing something right. Moreover, in these projects I had people who no matter what they were doing, they were always putting their 100% in it. It was somehow easy to get them engaged. At some point I figured out that they had engagement ingrained in them. And believe me you want to work with such people. People who don't give a damn, who are 'just earning money' are not fun to work with. They are inclined to take shortcuts, think short term and to look at you with 'what this has to do with me' face in the time of crisis. If you can - work with people who care about what they are doing.
As I mentioned earlier building up quality is all about incremental improvements, innovations which make your code better and better. And to innovate you have to stay up to date, learn and try new things. Think about your current quality as the status quo, comfort zone your developers live in. If you want them to get out of this cave they need to be curious enough to take action which would push them out. Given that they are wondering enough to see shadows and hear echoes in the first place. No progress without questioning, in short.
And finally thoroughness - this is the difficult one - most of the folks go into this business because of high payoffs for creative actions - you build up several routines and you are already running something which paints beautiful outputs to your screen, you change a bit of it and the outcomes are completely different and even better adjusted to what you wanted to get. This is what we all are for in this business. Unfortunately, if we want to make something more out of it than a creator's toy - after we have the prototype which works with input of our choice, we need to put ten times more work to make it work with all the inputs in all situations - and this is not so much fun any more. Ratio is different based on how you modeled domain in the first place, but still creative piece is always far shorter than the process of handling non-standard cases afterwards. To make things worse we know how to get next adrenaline fix - we just need to move on to creating next piece. It requires a lot of discipline to finish it up - I've been there - it took me many years to develop thoroughness and ingrain it into my character and I still have slips from time to time. Fortunately being able to do the task completely offers also good chemistry strike through your body and additionally good managers will be looking for you everywhere.
To sum this up - features commonly searched for like skills and creativity are for sure important, but at least my experience says that some character traits (which by the way would make you stand out in anything you put your hands to) are far more important than that.
Friday, November 21, 2008
On good manager - how to spend windowed office wisely
Last post was about insecure software manager vicious circle, so to balance it today I will talk about what I believe are the most desired features in managers’ CVs to scan for.
Task of finding a good manager is one of the important ones as difference on this element of the puzzle can give us results varying from a successful project on time (if you have your project delivered even earlier it's most likely time to wake up and go to work) to projects abandoned out of frustration by the whole crew, completely unmanageable, which you need to burn to the ground to avoid disease spreading. So unless you have magic idea how to capitalize on high turnover (if you have and you are still making software you are apparently missing something) you should look for a manager who would perform well.
So what makes a difference in manager performance? I would probably go for the following mix: integrity, ability to keep an eye on the target, ability to glue the team, ability to facilitate communication and minimize its costs. Let me elaborate a bit on that.
She has to have the integrity as there will be pressures from all directions - we have customers pushing for features, project sponsors pushing for return on investment, team pushing for nice neat innovations, economy pushing for savings - manager has to know the balance and has to level everything to keep it.
Similar story about maintaining the vision on what it is we are producing. Everybody else get their own partial perspective on the project - there is money view and features view and program characteristics view, internal construction view. Project sponsor is funding it to get more money out of it, developer is writing code to get PS3 for his 1-year old son. Project manager is the person who has to see from the project success perspective. Now this is a difficult task, because requirements, resources keep changing as we go (as we didn't put external world on standby). Project manager has to keep this running target under control and in sync.
Now let's look how the team works - from the workflow point of view, we work in iterations: participants are agreeing what they are working on (parts) and how it will connect to the rest of a whole (interfaces). Then they work on their parts and when finished they integrate the parts with the whole. Keep in mind that we are working on the mathematical model of a high complexity - there is a lot of communication required to make it happen and any miscommunication costs a lot. Project manager has to carefully develop environment, which promotes easy flowing communication. All disrupting factors like interpersonal conflicts, prima donnas, special procedures for communication have to be resolved at all costs. Manager should also seek to find ways to provide people with information in a way, which doesn't get them out of their zones or put them on documentation pages for hours. She should also at all costs make sure that nobody feels overlooked there.
Now to the gluing part - I've worked with many teams in my life, and I can see two patterns really - either people are engaged into the project and work as a team, are proud of being a member of the team, help each other, or they are there to earn money, doing what they are asked to but never going an extra inch in project cause. Performances of both teams differ drastically - I've never done proper measurement, but I think factor of ten is not unreasonable. If you want to check which of the two your team is, check whether most of the team is sitting on their chairs 5.03pm - if they are then there is a pretty good chance they are engaged. By the way if they are still there at 6pm you have another kind of problem, but this is for another occasion. If you are a manager and cannot check whether they are there at 5.03pm because you are in the car already you not only can safely bet they aren't but you have also serious suspicion for what is causing it. To be honest I've never figured out what does the gluing - I had teams working on similar projects on two completely different ends of this scale. The only hints I can give here is: treat people seriously, be honest and be friendly.
And remember you are there no to demand. You are there to help.
Task of finding a good manager is one of the important ones as difference on this element of the puzzle can give us results varying from a successful project on time (if you have your project delivered even earlier it's most likely time to wake up and go to work) to projects abandoned out of frustration by the whole crew, completely unmanageable, which you need to burn to the ground to avoid disease spreading. So unless you have magic idea how to capitalize on high turnover (if you have and you are still making software you are apparently missing something) you should look for a manager who would perform well.
So what makes a difference in manager performance? I would probably go for the following mix: integrity, ability to keep an eye on the target, ability to glue the team, ability to facilitate communication and minimize its costs. Let me elaborate a bit on that.
She has to have the integrity as there will be pressures from all directions - we have customers pushing for features, project sponsors pushing for return on investment, team pushing for nice neat innovations, economy pushing for savings - manager has to know the balance and has to level everything to keep it.
Similar story about maintaining the vision on what it is we are producing. Everybody else get their own partial perspective on the project - there is money view and features view and program characteristics view, internal construction view. Project sponsor is funding it to get more money out of it, developer is writing code to get PS3 for his 1-year old son. Project manager is the person who has to see from the project success perspective. Now this is a difficult task, because requirements, resources keep changing as we go (as we didn't put external world on standby). Project manager has to keep this running target under control and in sync.
Now let's look how the team works - from the workflow point of view, we work in iterations: participants are agreeing what they are working on (parts) and how it will connect to the rest of a whole (interfaces). Then they work on their parts and when finished they integrate the parts with the whole. Keep in mind that we are working on the mathematical model of a high complexity - there is a lot of communication required to make it happen and any miscommunication costs a lot. Project manager has to carefully develop environment, which promotes easy flowing communication. All disrupting factors like interpersonal conflicts, prima donnas, special procedures for communication have to be resolved at all costs. Manager should also seek to find ways to provide people with information in a way, which doesn't get them out of their zones or put them on documentation pages for hours. She should also at all costs make sure that nobody feels overlooked there.
Now to the gluing part - I've worked with many teams in my life, and I can see two patterns really - either people are engaged into the project and work as a team, are proud of being a member of the team, help each other, or they are there to earn money, doing what they are asked to but never going an extra inch in project cause. Performances of both teams differ drastically - I've never done proper measurement, but I think factor of ten is not unreasonable. If you want to check which of the two your team is, check whether most of the team is sitting on their chairs 5.03pm - if they are then there is a pretty good chance they are engaged. By the way if they are still there at 6pm you have another kind of problem, but this is for another occasion. If you are a manager and cannot check whether they are there at 5.03pm because you are in the car already you not only can safely bet they aren't but you have also serious suspicion for what is causing it. To be honest I've never figured out what does the gluing - I had teams working on similar projects on two completely different ends of this scale. The only hints I can give here is: treat people seriously, be honest and be friendly.
And remember you are there no to demand. You are there to help.
Wednesday, November 19, 2008
Continuously degrading quality - insecure manager kills it all
Software programs tend (still) to be created by people - so it's quite likely that different people would create software of different quality. There is a whole bunch of people who are involved during project creation - we have product managers, project managers, project sponsors, architects, team leads, software developers, graphic designers, docs people, qa people etc. Let's divide them into two groups: managers (people responsible for overall outcome) and developers (people who develop parts of actual product). Trying to refocus from how big this oversimplification is let's try to figure what are the desired characteristics for the manager. Or maybe let's try an easier path and leave the desired stuff for later - what actually should be avoided at all costs when you are looking for a good manager to take on your project.
Based on my experience if there is a single thing I could say to a software manager sitting next to my death bed (I don't think I'll get that lucky...) - that would be: 'do no harm'.
Why is that? Because managers are the people who do most harm during software project creation. They are usually responsible for project failures. Am I saying managers are idiots? Not at all. Managers are usually the most experienced and wise people in the project. But...
Managers have extremely hard life: they are not much smarter (if at all) than the rest of the team in which they are supposed to be power figures. Remember that we are talking about ecosystem in which the main survival skill is mathematics. It's not easy to compete with pale-face, skinny-bodied mathema-males. But the manager has to have respect in this world to lead the project to desired outcome.
Additionally managers do not have measure work units which they could present to their masters if required. There is no I did 20 pounds of managing today which is well above my last year average. They are supposed to define a course and if the boat deviates from it put corrections in place.
So project management seems like easy money. Start the thing up, anticipate problems and help team prevent them or overcome them. Make sure communication within the team doesn't go off limits and protect team from the external world.
The rest of the time sit in the office and do not distract others.
This is where it gets weak when experienced by insecure manager:
if I'm not doing anything apparently there is something wrong and my masters would not be happy with me. I need to help my team. I will get involved in some technical meetings, I will argue with technicians on technical stuff, to defend my position in the team as a power figure I will be winning arguments using 'because I say so' approach. Seeing morale plunging I will design some sophisticated work review procedures and add some procedures to uniform the team. I will talk to developers with sad voice about their performance to make them improve. At the end I might not be happy and they will probably seem miserable but whatever it takes to deliver the project. Maybe late and maybe not really tested, but we for sure all worked hard every minute of our time...
So if you are a manager please remember 'do no harm' - especially if you are insecure. If you don't calculate both benefits and costs of introducing new practice, don't introduce it. If you are not sure of the outcome of the new experiment don't start it.
And if you are insecure fight your insecurity with all power you have for Christ sake - you are a manager now, you are supposed to lead people.
Based on my experience if there is a single thing I could say to a software manager sitting next to my death bed (I don't think I'll get that lucky...) - that would be: 'do no harm'.
Why is that? Because managers are the people who do most harm during software project creation. They are usually responsible for project failures. Am I saying managers are idiots? Not at all. Managers are usually the most experienced and wise people in the project. But...
Managers have extremely hard life: they are not much smarter (if at all) than the rest of the team in which they are supposed to be power figures. Remember that we are talking about ecosystem in which the main survival skill is mathematics. It's not easy to compete with pale-face, skinny-bodied mathema-males. But the manager has to have respect in this world to lead the project to desired outcome.
Additionally managers do not have measure work units which they could present to their masters if required. There is no I did 20 pounds of managing today which is well above my last year average. They are supposed to define a course and if the boat deviates from it put corrections in place.
So project management seems like easy money. Start the thing up, anticipate problems and help team prevent them or overcome them. Make sure communication within the team doesn't go off limits and protect team from the external world.
The rest of the time sit in the office and do not distract others.
This is where it gets weak when experienced by insecure manager:
if I'm not doing anything apparently there is something wrong and my masters would not be happy with me. I need to help my team. I will get involved in some technical meetings, I will argue with technicians on technical stuff, to defend my position in the team as a power figure I will be winning arguments using 'because I say so' approach. Seeing morale plunging I will design some sophisticated work review procedures and add some procedures to uniform the team. I will talk to developers with sad voice about their performance to make them improve. At the end I might not be happy and they will probably seem miserable but whatever it takes to deliver the project. Maybe late and maybe not really tested, but we for sure all worked hard every minute of our time...
So if you are a manager please remember 'do no harm' - especially if you are insecure. If you don't calculate both benefits and costs of introducing new practice, don't introduce it. If you are not sure of the outcome of the new experiment don't start it.
And if you are insecure fight your insecurity with all power you have for Christ sake - you are a manager now, you are supposed to lead people.
Subscribe to:
Posts (Atom)
Posts
