We are releasing some new software soon and I discovered that the developer put in some extra functionality. This functionality was not requested; He just thought that it would be valuable in case there was ever an issue and we needed to trace things back.
He had mentioned it to me some time ago but I didn't understand the full gist of it and I let it go. However, just the other day we were testing our software and a bug related to this feature came up. So he's putting in a fix for this. The bug was the result of doing some a-typical behavior but nonetheless it's something that should be resolved once detected.
However my concern is with why is that feature there in the first place? It was never requested. Developers need to understand that adding new features comes at a price. I not only serve as PM, but also BA & QA on this project. I am also the PM on multiple other projects and my time is limited. Adding any new feature => (means) adding more code => creating additional pathways => testing more code. This can grow exponentially. Simply put, the price you pay is additional testing time but also increased probability of bugs.
Users who request features with abandon and software teams who accomodate them get into lots of problems. Feature requests need to really be evaluated for the payoff they'll deliver. The thing with software is that it is invisible; you can't touch it or taste it or see it. So it's easy to overlook the amount of time, effort & money that goes into producing it. This message needs to be constantly sent to users in the form of pushing back or pricing each feature. Say No if you don't believe the feature will provide enough value vs. what will go into producing it. Or give a price tag: if they want something the user will have to pay for it somehow: either monetarily (cash, budget xfer, etc) or time-wise (this will delay the next feature x amount of days/months, etc)
You constantly need to remind users of the cost of producing quality software (and that includes QA time). It's easy to forget. Again, I need to point to the guys at 37signals.com; They turn down LOTS of feature requests in their quest to keep their software bug free and clutter free.
Wednesday, November 24, 2010
Friday, November 12, 2010
Project Management Tip #1
I was going to write a top 10 list but the first one alone is enough for a post! So here is Tip #1:
Email Communication
When I see email sent from colleagues to several people in the To line and the cc line, I am still amazed to see that people don't address things to specific people.
An e.g. of a bad communication:
"Yes, I agree. IT needs to check whether we have connectivity via Radianz BT to the exchange. Once we know that, Operations can go ahead and request the appropriate credentials to get us going"
Seems like a normal piece of communication. But it's not very effective. Why?
IT & Operations are huge! If the above email was sent to one person, that person know s/he knows to do something, but if you have a number of people on the list, then (and this is the most pervasive thinking around), everyone assumes someone else is doing it! It baffles me to this day why people who send such email also sit around and complain that nothing gets done...
Much more effective would be:
"Yes, I agree. Steve, can you check whether we have connectivity via Radianz BT to the exchange. Once you confirm that, let Rick in Operations know so he can request the appropriate credentials to get us going."
PUT ACTUAL NAMES against tasks! This actually shows that the delegator knows his/her co-workers and their responsibilities which is nice (don't you feel good if a manager knows that you're responsible or good at something?) I even use this tactic if I'm not sure who the right person is. I may just take an educated guess. One thing I know for certain: If I address it to the wrong person, that person will reply back *right-away* and say "I don't do that. Jason handles that" and now I know that Jason should be handling it!
Email Communication
When I see email sent from colleagues to several people in the To line and the cc line, I am still amazed to see that people don't address things to specific people.
An e.g. of a bad communication:
"Yes, I agree. IT needs to check whether we have connectivity via Radianz BT to the exchange. Once we know that, Operations can go ahead and request the appropriate credentials to get us going"
Seems like a normal piece of communication. But it's not very effective. Why?
IT & Operations are huge! If the above email was sent to one person, that person know s/he knows to do something, but if you have a number of people on the list, then (and this is the most pervasive thinking around), everyone assumes someone else is doing it! It baffles me to this day why people who send such email also sit around and complain that nothing gets done...
Much more effective would be:
"Yes, I agree. Steve, can you check whether we have connectivity via Radianz BT to the exchange. Once you confirm that, let Rick in Operations know so he can request the appropriate credentials to get us going."
PUT ACTUAL NAMES against tasks! This actually shows that the delegator knows his/her co-workers and their responsibilities which is nice (don't you feel good if a manager knows that you're responsible or good at something?) I even use this tactic if I'm not sure who the right person is. I may just take an educated guess. One thing I know for certain: If I address it to the wrong person, that person will reply back *right-away* and say "I don't do that. Jason handles that" and now I know that Jason should be handling it!
Monday, November 1, 2010
The Dangers of Bad Project Management
Bad Project Management gives all Project Managers a bad name!
Done badly, it actually can scar one for life and diminish management's effectiveness in running an organization.
Too many people have the notion that all project management is is: issuing tasks for people to do, and hounding people for status. A lot of people think project managers add no value. And I would have to agree: if this is all they are doing, then they are probably not contributing much at all and detract from the project. This kind of project management gives us all a bad image. However, it just doesn't stop there. The damage becomes pervasive: People who have *never even been managed* on a project learn from their peers and others in the organization the attitude of "Oh no, we gotta listen to this guy" and watch as their colleagues roll their eyes at the PM who doesn't know what s/he is talking about.
PMs are caught in the middle between senior management and the people doing the work. From a senior management point of view, if I plan a strategy and want to execute, I look to my PMs to implement that strategy. They are my levers to push and pull on to get the organization to move in a certain direction. So as a senior manager, I need to have trust in my PMs. If I have a negative view of Project Managers, I'll never place much faith in them and empower them to get the job done. I might second-guess, or micro-manage them; basically doing their job for them. That would put me at risk of losing my own job.
I'm sure there are senior managers who have these attitudes but those who are effective senior managers believe in the virtues of effective project management and have seen that it truly is the way to get things done.
My concern is more with the people doing the work. We should be more worried about the effect of project management on the line workers and those in the functional areas. If they're disillusioned by project management and its practices, they won't execute and the whole practice becomes a failure. Many of them have been burned by the application of bad principles, or principles inexpertly or inappropriately applied. (e.g., long, wasteful meetings with too many people or the opposite: badly run scrum meetings) or bad PMs (who stay above the fray and don't get involved and miss key details, report wrong facts, etc). This has a cascade effect as I mentioned above: they don't feel utilized or listened to; they feel ineffectual or that the project isn't going anywhere or headed in the wrong direction or it may simply stall because decisions aren't being made => other colleagues become infected. These personnel may start to look for work elsewhere. The problem with this is they carry the same negative views of project managers with them where ever they go & history can easily repeat itself.
So what's the remedy? Simple! (but more difficult in practice) Hire good PMs; PMs who aren't afraid to get into the guts of the project; to sit down with a BA and have them make that call to the customer to clarify a requirement (I did this just the other day because the BA sounded unsure of what the customer was asking for) or to sit with a developer and get into the details of why something is not working. You don't have to have a particular skillset to do this. You don't have to solve the problem. But just listening alone shows others that you are deeply involved and care what's going on: that you're all one team. And this is the most important thing in project management: Operating as a team.
Project Managers are leaders by definition. Thus they need to also model the behaviors that go into successful execution of tasks. If a BA is uncertain of something, call up the customer. If a developer doesn't know how to proceed, suggest things to google, etc.
Done badly, it actually can scar one for life and diminish management's effectiveness in running an organization.
Too many people have the notion that all project management is is: issuing tasks for people to do, and hounding people for status. A lot of people think project managers add no value. And I would have to agree: if this is all they are doing, then they are probably not contributing much at all and detract from the project. This kind of project management gives us all a bad image. However, it just doesn't stop there. The damage becomes pervasive: People who have *never even been managed* on a project learn from their peers and others in the organization the attitude of "Oh no, we gotta listen to this guy" and watch as their colleagues roll their eyes at the PM who doesn't know what s/he is talking about.
PMs are caught in the middle between senior management and the people doing the work. From a senior management point of view, if I plan a strategy and want to execute, I look to my PMs to implement that strategy. They are my levers to push and pull on to get the organization to move in a certain direction. So as a senior manager, I need to have trust in my PMs. If I have a negative view of Project Managers, I'll never place much faith in them and empower them to get the job done. I might second-guess, or micro-manage them; basically doing their job for them. That would put me at risk of losing my own job.
I'm sure there are senior managers who have these attitudes but those who are effective senior managers believe in the virtues of effective project management and have seen that it truly is the way to get things done.
My concern is more with the people doing the work. We should be more worried about the effect of project management on the line workers and those in the functional areas. If they're disillusioned by project management and its practices, they won't execute and the whole practice becomes a failure. Many of them have been burned by the application of bad principles, or principles inexpertly or inappropriately applied. (e.g., long, wasteful meetings with too many people or the opposite: badly run scrum meetings) or bad PMs (who stay above the fray and don't get involved and miss key details, report wrong facts, etc). This has a cascade effect as I mentioned above: they don't feel utilized or listened to; they feel ineffectual or that the project isn't going anywhere or headed in the wrong direction or it may simply stall because decisions aren't being made => other colleagues become infected. These personnel may start to look for work elsewhere. The problem with this is they carry the same negative views of project managers with them where ever they go & history can easily repeat itself.
So what's the remedy? Simple! (but more difficult in practice) Hire good PMs; PMs who aren't afraid to get into the guts of the project; to sit down with a BA and have them make that call to the customer to clarify a requirement (I did this just the other day because the BA sounded unsure of what the customer was asking for) or to sit with a developer and get into the details of why something is not working. You don't have to have a particular skillset to do this. You don't have to solve the problem. But just listening alone shows others that you are deeply involved and care what's going on: that you're all one team. And this is the most important thing in project management: Operating as a team.
Project Managers are leaders by definition. Thus they need to also model the behaviors that go into successful execution of tasks. If a BA is uncertain of something, call up the customer. If a developer doesn't know how to proceed, suggest things to google, etc.
Subscribe to:
Posts (Atom)