It's official. I have done it. I am now a PMI-certified Project Management Professional (PMP)!
I took the exam yesterday (29-Dec) and spent a little over 3 hours on it. When I hit the submit button to finish the exam, I was fairly confident that I would pass. In fact, during my entire preparation I had full confidence that passing this exam was inevitable.
The reason for my confidence is that I had fully project-planned my entire PMP experience! I made the goal of attaining the PMP back about May 2010. I then realized my company was offering a prep course for the PMP exam in November. I signed up for the course and targeted December as to when I would take the exam. So my milestones were set!
I signed up to become a member of PMI & my local chapter in mid-June. I then spent Saturdays going into the office over the summer to count up my hours. To aid in this, I scoured the web for a spreadsheet that would enable me to easily count my hours. I found one and several Saturdays in June, July & August were spent tallying these hours going back 3-4 years.
The next step was to get these hours into the PMI website. I'll admit there was some slight procrastination here :) Actually, I already had a lot of slack for this task. The hard part was counting the hours. All that was left was data entry. So one Friday night, I stayed late at work and entered all the hours.
The next step came in November when I took the PMP course. I missed a lot of it because of work issues that came up, but the materials in the class were invaluable. It was taught by ESI and I got all their study aids as well as the 9-disc CD set for each knowledge area. I then decided to set a date for the exam in late December and made that my target. For over a month, I studied: Listened to the CDs, read the PMBOK, did practice questions, downloaded PMP apps for the iphone that I could play with on the subway; After this initial stage, I deep-dived (dove?) into each knowledge area. I bought the Head-First PMP book and did the entire book. I then re-took the practice questions from Stage 1, elevating all my previous scores to about 90% and higher. I was already sure that I would pass the exam at this stage. I then took a full comprehensive test exam that ESI provided me with and then the online Head-First PMP exam. On both I scored 85 % and higher.
I then just practiced writing down a few formulas and making sure I knew them cold. And that was it!
It's really amazing how planning this whole endeavor worked so well. I executed flawlessly and mission accomplished!
So tips for passing the PMP: I don't have much to add that would improve upon what many others out there already advocate. Just that you should know your own style of studying. I am an accomplished test taker and so I already knew what would be the most effective for me. Do the same for yourself and you should be fine. A little discipline goes a long way!
Thursday, December 30, 2010
Friday, December 3, 2010
Cross-Managing
One of the most valuable things I've heard on my project management journey is "If you want to be a project manager, you have to first learn to be managed". I was puzzled by this but it was so zen-sounding, I just knew there was some truth in it. That was several years ago and since then I've seen the truth of that statement everywhere. Many people want so badly to be "managers" and feel that by getting their PMPs & learning to delegate, they will have made it in the project management profession. They don't want to put in the time to learn the tasks they need to do their current job really well. They do the tasks to get them over with so they can get onto the next "bigger" thing. In other words, they become close to "un-manageable" in the job they are already in. Why would a senior person trust such a person with an important project to do if they are unable to perform their current job really well?
That's the way to grow in this business of business: Perform excellent work *now* in whichever role or function you're in. Gradually you begin to build yourself up and show yourself capable. Then people everywhere come to see you as reliable and you will increasingly get more work (which is a good thing!) Before you know it, you will become a manager!
However, it doesn't stop there. The entire business of management is not only top down, but also bottom-up (as I've blogged about here: Managing Up). Now, I have yet another addition: Managing Across! What does this mean? It means managing people on initiatives/requests that you have no direct relationship with. So for e.g., since I am in IT, I have no direct relationship with someone in Expense Management or Credit. However they may ask me for something or I might need something from them. There is no on-going project that we're all involved in. Usually it's something like a one-off request. And yes, this can easily be seen as a distraction from current project work. And people may not respond with alacrity. Or they may not respond at all! In fact in some circumstances, you may need to escalate to get your request fulfilled. So in this case, there's nothing really in the PMBOK guide that addresses such circumstances (or actually there may be; I just haven't looked closely enough). However, some of the techniques that are used for managing people in general can be valuable here as well.
Here are a few:
That's the way to grow in this business of business: Perform excellent work *now* in whichever role or function you're in. Gradually you begin to build yourself up and show yourself capable. Then people everywhere come to see you as reliable and you will increasingly get more work (which is a good thing!) Before you know it, you will become a manager!
However, it doesn't stop there. The entire business of management is not only top down, but also bottom-up (as I've blogged about here: Managing Up). Now, I have yet another addition: Managing Across! What does this mean? It means managing people on initiatives/requests that you have no direct relationship with. So for e.g., since I am in IT, I have no direct relationship with someone in Expense Management or Credit. However they may ask me for something or I might need something from them. There is no on-going project that we're all involved in. Usually it's something like a one-off request. And yes, this can easily be seen as a distraction from current project work. And people may not respond with alacrity. Or they may not respond at all! In fact in some circumstances, you may need to escalate to get your request fulfilled. So in this case, there's nothing really in the PMBOK guide that addresses such circumstances (or actually there may be; I just haven't looked closely enough). However, some of the techniques that are used for managing people in general can be valuable here as well.
Here are a few:
- Ask for a favor
- Make the request as simple as possible
- Make a phone-call OR send an email and then follow up with a phone call: a personal touch is much more effective than an email to someone you don't know
- Thank them!
- When someone requests something of you in a similar fashion, respond with alacrity and be helpful
Managing Across is yet another opportunity to learn to be managed. We're managed by our bosses, but we can also be managed by colleagues in other parts of the organizations to provide them help/information. It's a constant exercise and requires discipline. There is no point at which you will NOT be managed.
In fact, if I can get philosophical, Life is the greatest manager of them all. Life constantly introduces new stresses and pressures; it changes directions on all of us & sometimes does so whimsically. We all are managed by life in one way or another. So how do you deal with it?
The answer: Being managed at work is a microcosm of life in general and serves as excellent practice! So if you find yourself getting frustrated by requests from others or "distracted" from your project, treat that as an opportunity to be managed. How you respond in such circumstances will be an indicator of how you respond to your life in general.
The answer: Being managed at work is a microcosm of life in general and serves as excellent practice! So if you find yourself getting frustrated by requests from others or "distracted" from your project, treat that as an opportunity to be managed. How you respond in such circumstances will be an indicator of how you respond to your life in general.
Wednesday, November 24, 2010
Too Much Code!
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.
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.
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.
Wednesday, October 27, 2010
Don't bring me problems; bring me solutions!
or "Don't come to me with a problem if you don't have a solution"
These sayings are some things I've heard along the course of my career.
Now, when I first heard it, I thought it was dumb. I mean why the heck else would I approach my boss? If I didn't have a clue how to fix a problem, then why *shouldn't* I go to my boss?
But just as in observing a jewel & its many facets, there are many ways to interpret the above remarks...
A few experiences have shifted my attitude from the one I previously held.
1. I encountered an issue at work and realized it needed to be addressed with a higher priority than some projects that I was managing currently. I called my manager and told him about this new problem. He seemed to be pretty busy but listened to me and then came right to the point: "What do you need to do?" My first reaction was to feel put on the spot. I thought he'd want to mull it over, hash it out, conduct an exercise in re-prioritization, etc. But instead I responded with "I need a developer and it will take 2 weeks ". He said, "OK, it's important. Do it". Problem solved...
If I were to have not thought of a solution and simply told him the problem and stopped there, I wouldn't have added any true value. I just would have laid the problem at his doorstep and waited for instructions. That's not what I get paid to do. In that moment that I felt put on the spot, I was able to move past it & instead respond with my proposed solution and so he was able to make a decision and give the go-ahead. This is what being pro-active is all about and in that moment, I realized the truth of those sayings above.
2. I had a discussion with a medical doctor about this very same topic and she expressed to me the parallels of this in her own work. She supervises residents who would call her up with the patient's condition and explain things to her. Then silence... The residents wait for her to tell them what they should do. She can of course easily do that. She knows what needs to be done. But residency is training for medical doctors. So she simply turns the tables and asks them what they want to do. "They can suggest the craziest things; it's OK. We don't have to do it, but they need to generate ideas" is what she said. She can identify the good doctors from the not-so-good ones from interactions like these.
I'm not saying that you can't go to your manager with problems. Your manager is supposed to guide you and if you have no clue about how to go about something, then by all means ask your manager. The saying is just a reminder that we always have more power than we think in creating solutions to the problems we encounter.
Sunday, October 17, 2010
The Apprentice, Donald Trump & Project Management
The last time I watched the Apprentice was several years ago (probably more than that even: Omarosa anyone?!). I only had a faint idea of what a project manager did. I never gave it much thought. After all it was just entertainment.
However, I have recently caught a few episodes this season (Season #10) and it hit me that this is exactly what I do for a living! (I only embraced the formal role of PM a little over 2 years ago).
So I've been paying more attention this time around in the hopes of seeing if I could glean something valuable to take back to work. Unfortunately, I haven't learned much, except in the category of what-NOT-to-do!
The premise of the show is such that it pits people against each other from the get-go. Instead of focusing on a task and pulling together as a team, people are simultaneously trying to win the task but also plotting how to cast others in the worst possible light. If that happened in the military, on a sports team or some other organization that was actually trying to achieve something, those kinds of people would be kicked out. Except on "The Apprentice", they're kept around for entertainment.
One idea that I've picked up the last few years is the idea of surrender vs. succumb. I don't mean the literal dictionary meanings but actually from a different perspective. Let me re-define them:
First, succumb: To succumb to something is to give in and accept defeat, but you will make the other person wrong for it. So it wasn't your idea to watch "When Harry Met Sally"; it was your partner's. You actually wanted to watch "Batman", but fine... you'll watch it but you won't have a good time. You'll also ensure your partner doesn't have a good time by punishing him/her so you both don't have a good time.
Now surrender: To surrender to something is to give in as well *but then to treat it as if it was your idea in the first place* How novel! So it wasn't your idea to watch "When Harry Met Sally", but you know what? Why the hell not? It sounds like a blast. I'll go microwave the popcorn. You get the blankets! This creates a win-win situation. You don't punish anyone. In fact you both have a great time.
Believe it or not, this is actually possible! Lots of people go through life not even knowing that this alternative exists. But it does. And the funny thing is: you even forget you wanted to watch Batman in the first place. Life just moves on and you along with it...
So back to the Apprentice. If the teammates could actually allow themselves to be guided by the Project Manager and surrender to his/her decisions, they might actually win consistently and *never* even go into the boardroom! Now that would be a sight... I'm not saying that the Project Manager should be allowed to do whatever s/he pleases; after all, multiple perspectives and collaboration is necessary to decide how to tackle the challenges they are presented with. However, after a decision is made, the teammates squabbling and acting out (succumbing and dragging their feet) doesn't help achieve the objective. In fact it slows them all down, creates a hostile/negative working environment, purges creative energies from the team and makes them vulnerable to losing.
However, I have recently caught a few episodes this season (Season #10) and it hit me that this is exactly what I do for a living! (I only embraced the formal role of PM a little over 2 years ago).
So I've been paying more attention this time around in the hopes of seeing if I could glean something valuable to take back to work. Unfortunately, I haven't learned much, except in the category of what-NOT-to-do!
The premise of the show is such that it pits people against each other from the get-go. Instead of focusing on a task and pulling together as a team, people are simultaneously trying to win the task but also plotting how to cast others in the worst possible light. If that happened in the military, on a sports team or some other organization that was actually trying to achieve something, those kinds of people would be kicked out. Except on "The Apprentice", they're kept around for entertainment.
One idea that I've picked up the last few years is the idea of surrender vs. succumb. I don't mean the literal dictionary meanings but actually from a different perspective. Let me re-define them:
First, succumb: To succumb to something is to give in and accept defeat, but you will make the other person wrong for it. So it wasn't your idea to watch "When Harry Met Sally"; it was your partner's. You actually wanted to watch "Batman", but fine... you'll watch it but you won't have a good time. You'll also ensure your partner doesn't have a good time by punishing him/her so you both don't have a good time.
Now surrender: To surrender to something is to give in as well *but then to treat it as if it was your idea in the first place* How novel! So it wasn't your idea to watch "When Harry Met Sally", but you know what? Why the hell not? It sounds like a blast. I'll go microwave the popcorn. You get the blankets! This creates a win-win situation. You don't punish anyone. In fact you both have a great time.
Believe it or not, this is actually possible! Lots of people go through life not even knowing that this alternative exists. But it does. And the funny thing is: you even forget you wanted to watch Batman in the first place. Life just moves on and you along with it...
So back to the Apprentice. If the teammates could actually allow themselves to be guided by the Project Manager and surrender to his/her decisions, they might actually win consistently and *never* even go into the boardroom! Now that would be a sight... I'm not saying that the Project Manager should be allowed to do whatever s/he pleases; after all, multiple perspectives and collaboration is necessary to decide how to tackle the challenges they are presented with. However, after a decision is made, the teammates squabbling and acting out (succumbing and dragging their feet) doesn't help achieve the objective. In fact it slows them all down, creates a hostile/negative working environment, purges creative energies from the team and makes them vulnerable to losing.
Meeting hatred!
There's a short blog posting on the NYTimes CityRoom blog about meetings.
Meetings Post
The author absolutely *hates* meetings.
Here, take a look at this humorous poster on meetings.
Also, someone had posted this link about seeing how much meetings actually cost in real dollars (or euros, or other currencies): Meeting Timer; It's pretty cool. Just enter a few values and go! Watch the cost of your meeting add up. pretty scary!
I personally am agnostic about meetings. I've been to meetings which have been a waste of time of course. But I've been to other meetings where we've had to hash out real technical decisions and decide which way to proceed. Everyone's input was needed. A meeting is really the only way to arrive at those decisions.
Agendas are the key to having a good meeting. Know what the meeting is for: know its purpose going in. One meeting I held was because a senior member of the team didn't feel comfortable about a technical choice in the architecture that was made. The software was already tested and running fine and was a few days away from production release but this guy just didn't feel comfortable. So I held a meeting with him and a few other senior people. I quickly took everyone through the architecture, got everyone on the same page and then voiced his concern so we could all debate it. I actually thought that was a good meeting because everyone contributed and came away with an idea of what the architecture consisted of. This senior manager felt more comfortable as well. That was my primary objective actually: his acquiescence to what was going to be deployed. I didn't plan on having any action items come out of it nor did I want to address anything in the architecture that late in the game.
Project meetings where you don't come away with action items are basically a waste of time. When I am the Project Manager running meetings for my projects, I will also take on this responsibility of documenting the items. When I first started out as a PM, I didn't do this b/c I thought someone else would do it (big mistake!) just because 'someone else always did' (and it never used to be me!)
So then I started doing it. But then I realized there was a *huge* benefit for me to do this. It entitles me to become a 'revisionist' (as in revising history!). This sounds a bit dubious but it actually is quite a very useful practice. Let me explain where it come in most handy. In some meetings, there might often be those one or two stakeholders who don't have anything to do with the project itself but throw out 10 concerns: "You're going to want to check this, and then check that, but that might be ok, as long as you check this..." It's usually the case that these people are on the periphery of the project and will actually contribute no manpower whatsoever to the completion of it. They just want to be heard. (Pigs & chickens)
As PM, I believe I have license to do what it takes to get the project done. So on my action list after the meeting, I might conveniently leave out some of the suggested items that were brought up. This all depends on the exact concerns voiced or the level of influence of the stakeholders, etc. There have not been many instances where someone has emailed me back saying I missed something. And if they do, my response is to say "I'm sorry. I've added it now". Because if they do notice it's missing and actually write me about it, I'll take that as my cue that it actually is important. Life gives you the lessons when you need it the most...
Meetings Post
The author absolutely *hates* meetings.
Here, take a look at this humorous poster on meetings.
Also, someone had posted this link about seeing how much meetings actually cost in real dollars (or euros, or other currencies): Meeting Timer; It's pretty cool. Just enter a few values and go! Watch the cost of your meeting add up. pretty scary!
I personally am agnostic about meetings. I've been to meetings which have been a waste of time of course. But I've been to other meetings where we've had to hash out real technical decisions and decide which way to proceed. Everyone's input was needed. A meeting is really the only way to arrive at those decisions.
Agendas are the key to having a good meeting. Know what the meeting is for: know its purpose going in. One meeting I held was because a senior member of the team didn't feel comfortable about a technical choice in the architecture that was made. The software was already tested and running fine and was a few days away from production release but this guy just didn't feel comfortable. So I held a meeting with him and a few other senior people. I quickly took everyone through the architecture, got everyone on the same page and then voiced his concern so we could all debate it. I actually thought that was a good meeting because everyone contributed and came away with an idea of what the architecture consisted of. This senior manager felt more comfortable as well. That was my primary objective actually: his acquiescence to what was going to be deployed. I didn't plan on having any action items come out of it nor did I want to address anything in the architecture that late in the game.
Project meetings where you don't come away with action items are basically a waste of time. When I am the Project Manager running meetings for my projects, I will also take on this responsibility of documenting the items. When I first started out as a PM, I didn't do this b/c I thought someone else would do it (big mistake!) just because 'someone else always did' (and it never used to be me!)
So then I started doing it. But then I realized there was a *huge* benefit for me to do this. It entitles me to become a 'revisionist' (as in revising history!). This sounds a bit dubious but it actually is quite a very useful practice. Let me explain where it come in most handy. In some meetings, there might often be those one or two stakeholders who don't have anything to do with the project itself but throw out 10 concerns: "You're going to want to check this, and then check that, but that might be ok, as long as you check this..." It's usually the case that these people are on the periphery of the project and will actually contribute no manpower whatsoever to the completion of it. They just want to be heard. (Pigs & chickens)
As PM, I believe I have license to do what it takes to get the project done. So on my action list after the meeting, I might conveniently leave out some of the suggested items that were brought up. This all depends on the exact concerns voiced or the level of influence of the stakeholders, etc. There have not been many instances where someone has emailed me back saying I missed something. And if they do, my response is to say "I'm sorry. I've added it now". Because if they do notice it's missing and actually write me about it, I'll take that as my cue that it actually is important. Life gives you the lessons when you need it the most...
Saturday, October 16, 2010
The bright side of project practices
A good article on Projects @ Work about looking at the positives on projects rather than only concentrating on the negatives: On the Bright Side
The idea is to do MORE of the things that went well. Unfortunately, since the tendency is to concentrate on the bad and fix it, we forget the positives and to do more of those. Human beings' tendency to forget what went well and magnify what went wrong is epic. There are a # of studies in customer service that have shown that when a person has a positive experience at a business, s/he will tell 4 friends/acquaintances about it. However, if s/he had a negative experience, s/he will tell 9 friends/acquaintances about it! No wonder we quickly forget what went great and go for the bad...
In this vein, at my own workplace I am suggesting that PMs at the end of each project reflect and think about 3 things that went well about the project and that they would do again (so those are positively reinforced) and 1 or 2 not-so good things (so those could be rectified).
This kind of reflection will increase awareness of the positive things so we can bring those best practices forward into future projects.
The idea is to do MORE of the things that went well. Unfortunately, since the tendency is to concentrate on the bad and fix it, we forget the positives and to do more of those. Human beings' tendency to forget what went well and magnify what went wrong is epic. There are a # of studies in customer service that have shown that when a person has a positive experience at a business, s/he will tell 4 friends/acquaintances about it. However, if s/he had a negative experience, s/he will tell 9 friends/acquaintances about it! No wonder we quickly forget what went great and go for the bad...
In this vein, at my own workplace I am suggesting that PMs at the end of each project reflect and think about 3 things that went well about the project and that they would do again (so those are positively reinforced) and 1 or 2 not-so good things (so those could be rectified).
This kind of reflection will increase awareness of the positive things so we can bring those best practices forward into future projects.
Harry Potter & Project Management
This is a great post on the Unclutterer blog:
Post on JK Rowling's organization of Harry Potter
about how JK Rowling organized her thinking about the storylines of her Harry Potter series. I was never a Potter fan until last year. I dismissed the books as just for kids after summarily reading the first one. Luckily I picked it up again and just became entranced with the whole thing. I devoured all the books and movies one after the other. My life was put on hold until I was done... (I'm sure millions of fans around the world have had similar experiences).
In coming to appreciate the books, it dawned on me that Rowling's achievement was monumental. I was witness to a masterpiece: the books are elaborately crafted affairs with things happening in book 2 that don't rear their heads until books 5 or 6. She didn't just write the 1st book, and then after all the money came in, say "Oh that did well... Let me write another". No... she had these plotlines and twists organized from the very beginning! It is just amazing to see this mastery of organization in action!
Post on JK Rowling's organization of Harry Potter
about how JK Rowling organized her thinking about the storylines of her Harry Potter series. I was never a Potter fan until last year. I dismissed the books as just for kids after summarily reading the first one. Luckily I picked it up again and just became entranced with the whole thing. I devoured all the books and movies one after the other. My life was put on hold until I was done... (I'm sure millions of fans around the world have had similar experiences).
In coming to appreciate the books, it dawned on me that Rowling's achievement was monumental. I was witness to a masterpiece: the books are elaborately crafted affairs with things happening in book 2 that don't rear their heads until books 5 or 6. She didn't just write the 1st book, and then after all the money came in, say "Oh that did well... Let me write another". No... she had these plotlines and twists organized from the very beginning! It is just amazing to see this mastery of organization in action!
Friday, October 15, 2010
Communication within your Project Team
I saw some things today that really threw me a curveball. Let me explain:
I sank my claws into a new project today. It's basically a collection of 'tickets' that got lumped together and got called a project and prioritized. Each ticket goes through a cycle of requirements -> design -> coding -> QA -> UAT -> Release.
I started investigating one ticket in depth and talked to the architect reviewing the design to see if the suggested approach was feasible. After 15 minutes, I knew that what was being asked in the requirements was too big and that the best way to proceed forward was to descope some things. I called over the Business Analyst who wrote the requirements spec (and who luckily sits a few aisles over) to clarify. The architect went over his concerns and the BA understood and we quickly honed in on a much more tractable solution. The whole thing took about an hour. And furthermore, the solution was so simple, that the architect simply coded it himself! Now we can actually go ahead and test it!
However, it wasn't completely as smooth and easy as I described above. There were some valuable insights I gained from facilitating the interaction.
Some of the highlights are:
1. The architect thought the writer of the requirements document was in London because he assumed the person who created the ticket (who is in London) also had written the requirements; this was not the case. The author of the document was in NY but the architect never even looked at the cover page of the document! There would have been a lot of time wasted going back and forth with the person in London trying to get clarification on requirements when the 2 people who needed to talk most were both in the same location! It's really mind-boggling how something so simple can become so convoluted. We easily could have lost 2 or 3 days if the person in London got involved and tried to be the go-between.
2. We all know one of the functions of the BA is to translate business requirements into technical specs; basically being the go-between for business & IT. One doesn't think there needs to be any kind of translation within IT itself. It's easy to assume IT staff can all talk to one another and understand each other. In yet another twist of events, this assumption has also proven not to be true. In this particular case, the architect is very technical, repeats himself, and elaborates on points to an extreme degree. He is also a non-native speaker of English and speaks haltingly. It does take some effort to really listen and draw out the salient points. The BA isn't very technical and wanted things explained at a higher level. I facilitated the conversation between them. Where the BA didn't understand things, I stepped in to explain. In some cases I would cut off the long-winded explanations of the architect and other times I would ask him pointed, leading questions so he would emphasize something important.
It dawned on me that even within IT, it's dangerous to assume we all are on the same page. Miscommunication can easily happen between 2 co-located colleagues. (Note that this is the most ideal form of collaboration: a face-to-face meeting; yet it can still go horribly wrong!)
The larger lesson here is that a Project Manager with great listening skills can make a huge difference by facilitating interactions between the various members of the team and making sure everyone is clear on next steps. Many PMs just want to stay above the action and merely delegate the tasks to the team members and collect status items to report. They can add so much more value by delving into the details of the project alongside their teammates.
I sank my claws into a new project today. It's basically a collection of 'tickets' that got lumped together and got called a project and prioritized. Each ticket goes through a cycle of requirements -> design -> coding -> QA -> UAT -> Release.
I started investigating one ticket in depth and talked to the architect reviewing the design to see if the suggested approach was feasible. After 15 minutes, I knew that what was being asked in the requirements was too big and that the best way to proceed forward was to descope some things. I called over the Business Analyst who wrote the requirements spec (and who luckily sits a few aisles over) to clarify. The architect went over his concerns and the BA understood and we quickly honed in on a much more tractable solution. The whole thing took about an hour. And furthermore, the solution was so simple, that the architect simply coded it himself! Now we can actually go ahead and test it!
However, it wasn't completely as smooth and easy as I described above. There were some valuable insights I gained from facilitating the interaction.
Some of the highlights are:
1. The architect thought the writer of the requirements document was in London because he assumed the person who created the ticket (who is in London) also had written the requirements; this was not the case. The author of the document was in NY but the architect never even looked at the cover page of the document! There would have been a lot of time wasted going back and forth with the person in London trying to get clarification on requirements when the 2 people who needed to talk most were both in the same location! It's really mind-boggling how something so simple can become so convoluted. We easily could have lost 2 or 3 days if the person in London got involved and tried to be the go-between.
2. We all know one of the functions of the BA is to translate business requirements into technical specs; basically being the go-between for business & IT. One doesn't think there needs to be any kind of translation within IT itself. It's easy to assume IT staff can all talk to one another and understand each other. In yet another twist of events, this assumption has also proven not to be true. In this particular case, the architect is very technical, repeats himself, and elaborates on points to an extreme degree. He is also a non-native speaker of English and speaks haltingly. It does take some effort to really listen and draw out the salient points. The BA isn't very technical and wanted things explained at a higher level. I facilitated the conversation between them. Where the BA didn't understand things, I stepped in to explain. In some cases I would cut off the long-winded explanations of the architect and other times I would ask him pointed, leading questions so he would emphasize something important.
It dawned on me that even within IT, it's dangerous to assume we all are on the same page. Miscommunication can easily happen between 2 co-located colleagues. (Note that this is the most ideal form of collaboration: a face-to-face meeting; yet it can still go horribly wrong!)
The larger lesson here is that a Project Manager with great listening skills can make a huge difference by facilitating interactions between the various members of the team and making sure everyone is clear on next steps. Many PMs just want to stay above the action and merely delegate the tasks to the team members and collect status items to report. They can add so much more value by delving into the details of the project alongside their teammates.
Thursday, October 14, 2010
Making it in Financial IT
I subscribe to the Dice newsletter and there was an interesting article recently on Five Skills you need to Succeed in Financial IT. Click here
It's a good article and very accurate. Some of the things they get spot-on are:
It's a good article and very accurate. Some of the things they get spot-on are:
- "Educate yourself on both financial terminology and IT best practices," "This will allow you to truly understand your internal and external customers and provide a much higher level of service than someone who just has IT experience."
- While your job may include creating and managing trading platforms, that's not your real job. Your real job is to serve the clients, whether they're internal or external. You must know to communicate with people who are very different than you, who are under extreme pressure, and probably not very nice
I really like that they point out that the people we deal with are under extreme pressure and probably not very nice. Very true! You need to develop some objectivity and learn to not take things personally. It's about getting the job done. If you're worried about a bruised ego, you'll probably do better somewhere else. I learned this over the course of my career.
Tuesday, October 12, 2010
How many projects are too many?
Very interesting question posed in this article here: https://www.examiner.com/project-management-in-miami/how-many-projects-are-too-many-projects
It's actually an excellent question. I've been handed multiple projects simultaneously myself. Can I handle them all? How much is too much? Will I go crazy?
The article takes almost a mathematical approach, where you seemingly plug in values to a formula and out comes your answer: "Yes, that's too many" or "No, you can handle one more". Of course it doesn't do this explicitly, probably because it's actually impossible but the underlying message is that this problem is mathematically tractable and one can start to hone in on an answer.
I have a different viewpoint. Because by definition projects are unique, and you cannot predict the future, then there is no way you can even begin to apply some kind of calculus to the process. I wouldn't even try. I would let the PM make the determination as to what s/he can take on based on current bandwidth. Some of it is yes, calculated, but there's a whole other dimension involved: Intuition and gut instinct. This plays a much larger role than most people believe, I think.
The article in the link concludes with several tips for PMOs and senior management when assigning projects to Project Managers. However, this is only a one-sided communication. What's left out is: There always exists the possibility of the PM to say No: "No, my bandwidth right now is too limited."; "No, I'm still wrapping up this other project"; etc. Perhaps this is what is called for in some cases. Constantly saying yes to more projects without assessing what you're capable of spells doom for the project and the organization right from the get-go. Brutal honesty is required. Senior Managers must be made aware that there are consequences to their actions, whether it's pulling people off projects they think are 95% done and only a minor effort is left to get the project out the door (in my experience, that last 5% requires a LOT of attention to the details to get right; you cannot for a moment take your eye off the ball) or thinking you can at least initiate a new project early-on while juggling other projects (again, the first phase of a project: initiating/planning takes up an inordinate amount of time).
PMs know what goes into making a project successful; usually a lot of hard work, determination, persistence, constant attention to detail, etc. It's a very easy trap for people who are distant from the action (like senior managers) to think of projects as encapsulated pieces of work that they can juggle and shuffle around and that can be started and stopped on almost a whim. However, the reality is that there is a price to pay for context-switching: slowing down, changing tracks and getting back to speed all take time and energy, not to mention the impact of morale when projects people have devoted themselves to take a backseat or don't get completed.
An e.g.: I have a project that I was asked to manage but I have pushed back twice so far because of other priorities that have surfaced recently. I was tempted to start the project just because of my strong tendency to delve into the unknown and solve problems. However, I've had to hold myself back because I realized that once I started, I'd create an avalanche of expectations which I would then not be able to address because of lack of bandwidth. Again, this shows senior managers that their own choices (about priorities) have created this reality. It's important to have that feedback loop where people can see the consequences of their decisions and actions. Only then will people learn.
It's actually an excellent question. I've been handed multiple projects simultaneously myself. Can I handle them all? How much is too much? Will I go crazy?
The article takes almost a mathematical approach, where you seemingly plug in values to a formula and out comes your answer: "Yes, that's too many" or "No, you can handle one more". Of course it doesn't do this explicitly, probably because it's actually impossible but the underlying message is that this problem is mathematically tractable and one can start to hone in on an answer.
I have a different viewpoint. Because by definition projects are unique, and you cannot predict the future, then there is no way you can even begin to apply some kind of calculus to the process. I wouldn't even try. I would let the PM make the determination as to what s/he can take on based on current bandwidth. Some of it is yes, calculated, but there's a whole other dimension involved: Intuition and gut instinct. This plays a much larger role than most people believe, I think.
The article in the link concludes with several tips for PMOs and senior management when assigning projects to Project Managers. However, this is only a one-sided communication. What's left out is: There always exists the possibility of the PM to say No: "No, my bandwidth right now is too limited."; "No, I'm still wrapping up this other project"; etc. Perhaps this is what is called for in some cases. Constantly saying yes to more projects without assessing what you're capable of spells doom for the project and the organization right from the get-go. Brutal honesty is required. Senior Managers must be made aware that there are consequences to their actions, whether it's pulling people off projects they think are 95% done and only a minor effort is left to get the project out the door (in my experience, that last 5% requires a LOT of attention to the details to get right; you cannot for a moment take your eye off the ball) or thinking you can at least initiate a new project early-on while juggling other projects (again, the first phase of a project: initiating/planning takes up an inordinate amount of time).
PMs know what goes into making a project successful; usually a lot of hard work, determination, persistence, constant attention to detail, etc. It's a very easy trap for people who are distant from the action (like senior managers) to think of projects as encapsulated pieces of work that they can juggle and shuffle around and that can be started and stopped on almost a whim. However, the reality is that there is a price to pay for context-switching: slowing down, changing tracks and getting back to speed all take time and energy, not to mention the impact of morale when projects people have devoted themselves to take a backseat or don't get completed.
An e.g.: I have a project that I was asked to manage but I have pushed back twice so far because of other priorities that have surfaced recently. I was tempted to start the project just because of my strong tendency to delve into the unknown and solve problems. However, I've had to hold myself back because I realized that once I started, I'd create an avalanche of expectations which I would then not be able to address because of lack of bandwidth. Again, this shows senior managers that their own choices (about priorities) have created this reality. It's important to have that feedback loop where people can see the consequences of their decisions and actions. Only then will people learn.
Friday, October 8, 2010
Managing Up
The October issue of PM Network which is PMI's Monthly magazine is all about Leadership. I dove into it only today and have read a few articles but I highly recommend it.
You can access it here: Link to magazine
One interesting tidbit that resonated with me was in the Viewpoints column, called "Led Astray: Sometimes project leaders turn out to be their own worst enemies."
The last 2 paragraphs are about PMs failing to lead up: "Executives need managers who can give them the facts on the ground"... "If you are not effectively communicating to executives the detailed consequences of their decisions, then you only set yourself up to suffer."
How true! I've found this to be completely & utterly relevant to my own situation. I am almost done with a significant project. I have finished up the testing and we are planning the deployment for next week. The change requests to the production environment have been scheduled & approved. In the beginning of the week, however, the senior managers had shifted priorities on the next batch of projects and assigned me as the PM to two of them. They wanted me to start looking at these projects since I was wrapping up the one I mentioned above.
However, my gut instinct was "Hold on. We don't want to count our chickens before they've hatched". Even though the current project is in the deployment stage, there are still quite a few things that could go wrong. I let them know this and they agreed but they also said I could at least start a piece of it.
The thing with me is I like a challenge. I'm always raring to go, especially on new, unknown projects: I like to dive in and take the bulls by the horns. However, I also knew that if I started this project in earnest and started contacting stakeholders I would start creating expectations when I still had my previous project to finish up. Turns out that the project even in the final stages took some unexpected turns. My winding down of the project continued to be a full-time job! As soon as I realized my bandwidth was going to be consumed by some late requirements and shifting schedules, I shot off an email to the senior managers:
"It turns out that because of some late changing requirements and the recent schedule changes, that I need to conduct more tests...; I won't be able to devote time to the new project just yet. If I am able to finish up early, I will get onto this new project and will let you know. Until then, I suggest that the management of this initiative lie with so&so. Furthermore, I am scheduled for PM training on these dates..."
Done! I now had the responsibility of the project off my shoulders. I don't like to shirk off work. I don't like to let people down. I seriously weighed sending vs. not sending that email for a few minutes. But I eventually concluded that there was no way I was going to make any headway on this project as long as the previous project required my guidance.
There was no response to my email! No one convinced me that I could or should be able to do the new project. I got no complaints that I was incompetent or that I couldn't manage my time. They simply silently assented to what I told them. And I was free to devote my energies to finishing up the current project. Or at least bought another week :)
I knew that if I didn't push back on this new project or at least raise my concerns, then I would simply inherit the project and the managers would start asking me for status on the project, despite my having no bandwidth to get anything done. The memory of my having multiple projects would fade and only the weekly status of 0% accomplished would remain. It's important to raise concerns when you have them. Most of successful Project Management has to do with communication and this is a prime example. And this is an example of managing up. If you have no bandwidth, it's not a weakness to let your managers know this. Make it their problem, not yours. If you don't say anything, it automatically becomes *your* problem... and as the columnist wrote: "you have only set yourself up to suffer".
You can access it here: Link to magazine
One interesting tidbit that resonated with me was in the Viewpoints column, called "Led Astray: Sometimes project leaders turn out to be their own worst enemies."
The last 2 paragraphs are about PMs failing to lead up: "Executives need managers who can give them the facts on the ground"... "If you are not effectively communicating to executives the detailed consequences of their decisions, then you only set yourself up to suffer."
How true! I've found this to be completely & utterly relevant to my own situation. I am almost done with a significant project. I have finished up the testing and we are planning the deployment for next week. The change requests to the production environment have been scheduled & approved. In the beginning of the week, however, the senior managers had shifted priorities on the next batch of projects and assigned me as the PM to two of them. They wanted me to start looking at these projects since I was wrapping up the one I mentioned above.
However, my gut instinct was "Hold on. We don't want to count our chickens before they've hatched". Even though the current project is in the deployment stage, there are still quite a few things that could go wrong. I let them know this and they agreed but they also said I could at least start a piece of it.
The thing with me is I like a challenge. I'm always raring to go, especially on new, unknown projects: I like to dive in and take the bulls by the horns. However, I also knew that if I started this project in earnest and started contacting stakeholders I would start creating expectations when I still had my previous project to finish up. Turns out that the project even in the final stages took some unexpected turns. My winding down of the project continued to be a full-time job! As soon as I realized my bandwidth was going to be consumed by some late requirements and shifting schedules, I shot off an email to the senior managers:
"It turns out that because of some late changing requirements and the recent schedule changes, that I need to conduct more tests...
Done! I now had the responsibility of the project off my shoulders. I don't like to shirk off work. I don't like to let people down. I seriously weighed sending vs. not sending that email for a few minutes. But I eventually concluded that there was no way I was going to make any headway on this project as long as the previous project required my guidance.
There was no response to my email! No one convinced me that I could or should be able to do the new project. I got no complaints that I was incompetent or that I couldn't manage my time. They simply silently assented to what I told them. And I was free to devote my energies to finishing up the current project. Or at least bought another week :)
I knew that if I didn't push back on this new project or at least raise my concerns, then I would simply inherit the project and the managers would start asking me for status on the project, despite my having no bandwidth to get anything done. The memory of my having multiple projects would fade and only the weekly status of 0% accomplished would remain. It's important to raise concerns when you have them. Most of successful Project Management has to do with communication and this is a prime example. And this is an example of managing up. If you have no bandwidth, it's not a weakness to let your managers know this. Make it their problem, not yours. If you don't say anything, it automatically becomes *your* problem... and as the columnist wrote: "you have only set yourself up to suffer".
Sunday, October 3, 2010
Article on Personality Types: Business Analyst vs. Project Managers
Here's an article I had the pleasure of writing for the Projects@Work newsletter.
Link to Article: "Is Personality a Requirement, Too?"
You will need an account to sign in and read the entire article but it's a good site with lots of good information and I recommend it.
The origins of the article come from this earlier post on the same topic.
Link to Article: "Is Personality a Requirement, Too?"
You will need an account to sign in and read the entire article but it's a good site with lots of good information and I recommend it.
The origins of the article come from this earlier post on the same topic.
Thursday, September 30, 2010
Importance of Feedback
Coaching; Feedback; Important Stuff!
I've been thinking about this because of my latest passion: taking spinning classes!
Our minds tell us we have reached our breaking point and we possibly can't do anymore. But listening to the coach, he tells you to turn it up and if you listen and do it, you achieve way more than you possibly think you could have. All through the class, he kept telling us to turn the knob to the right, and I kept doing it; and then when the song ended and he told us to sit it down and ease up, I realized how far to the right I had twisted the knob and how difficult it was to keep spinning AND I KNEW that I myself would never have pushed myself to spin that hard!
There's a famous quote by Einstein:
"You cannot solve a problem from the same consciousness that created it. You must learn to see the world anew."
Listening to your mind, your own closed system of what's possible and what's not will NOT bring out your best. You need to be able to take direction from the outside. Coaching can really bring out your best. All top performers in any discipline require coaches; Coaches can see your true potential before even you can. Skilled coaches can bring out your true potential.
I would never have gotten to that difficult level of spinning on my own or even thought I was capable if the coach didn't push me to get there. It was simply out of my reality!
So whatever you're interested in: go seek a coach, mentor, buddy, whoever; Life Coaches, Executive Coaches, Personal Trainers, etc; go for it!
I've been thinking about this because of my latest passion: taking spinning classes!
Our minds tell us we have reached our breaking point and we possibly can't do anymore. But listening to the coach, he tells you to turn it up and if you listen and do it, you achieve way more than you possibly think you could have. All through the class, he kept telling us to turn the knob to the right, and I kept doing it; and then when the song ended and he told us to sit it down and ease up, I realized how far to the right I had twisted the knob and how difficult it was to keep spinning AND I KNEW that I myself would never have pushed myself to spin that hard!
There's a famous quote by Einstein:
"You cannot solve a problem from the same consciousness that created it. You must learn to see the world anew."
Listening to your mind, your own closed system of what's possible and what's not will NOT bring out your best. You need to be able to take direction from the outside. Coaching can really bring out your best. All top performers in any discipline require coaches; Coaches can see your true potential before even you can. Skilled coaches can bring out your true potential.
I would never have gotten to that difficult level of spinning on my own or even thought I was capable if the coach didn't push me to get there. It was simply out of my reality!
So whatever you're interested in: go seek a coach, mentor, buddy, whoever; Life Coaches, Executive Coaches, Personal Trainers, etc; go for it!
Sunday, September 19, 2010
Status Reports...for Yourself!
This is about Updating your weekly status reports even if it's for YOURSELF!
First of all, if you're a PM and you're not having regular reporting meetings (weekly, bi-weekly, monthly, whatever it is) with your boss, take the driver's seat and schedule them. S/he will be grateful for it.
If you have the attitude of seeing what you can get away with and not reporting status on your projects (like I did in the past), because you think there's not much to report, or you think you can coast for a while, then time to shift into overdrive! Making this into a routine practice is important for many reasons including:
Preparing the report ahead of time clarifies your thinking and makes you think of what exactly you want to report. You have to put yourself in your boss's shoes. You don't want to put too much detail in the report but you don't want to make it too high-level either. Only by understanding your boss's needs and how s/he thinks will you arrive at the appropriate level of detail.
Furthermore, preparing the report will allow you to see if you made any real progress since the last period. It will give you perspective on what you're actually accomplishing rather than what you tell yourself you think you accomplished. Nothing makes it more real than writing it down. Your thoughts are usually very different from reality! So think of these reports as reality checks.
My own manager was out of the office for the week (I have a weekly status meeting) and so I didn't have to prep for the meeting that week. However, I went through with the exercise anyway and it was very revealing. Acting as though I had a real status meeting, I was able to see what was accomplished, and what was not. There were milestones that were achieved but on a smaller scale so I had to break those down into more fine-grained milestones. I then folded these back into my project plan, estimated durations and came up with new dates. I was also able to assess risks, and contact stakeholders for more information. That to me was amazing. It represented real pro-active project management. And I had no one breathing down my back to do this. PMs need to be real driving forces in getting projects done. This is something I'll talk about in a future post.
First of all, if you're a PM and you're not having regular reporting meetings (weekly, bi-weekly, monthly, whatever it is) with your boss, take the driver's seat and schedule them. S/he will be grateful for it.
If you have the attitude of seeing what you can get away with and not reporting status on your projects (like I did in the past), because you think there's not much to report, or you think you can coast for a while, then time to shift into overdrive! Making this into a routine practice is important for many reasons including:
- Your boss doesn't have to chase you and wonder how the project is faring
- You get the help you need: Even if you have it under control, your boss may have an alternate viewpoint or helpful tips or stakeholders you need to consult to make sure you have all the bases covered, etc.
- Your boss can help your with risk assessment and mitigation
Preparing the report ahead of time clarifies your thinking and makes you think of what exactly you want to report. You have to put yourself in your boss's shoes. You don't want to put too much detail in the report but you don't want to make it too high-level either. Only by understanding your boss's needs and how s/he thinks will you arrive at the appropriate level of detail.
Furthermore, preparing the report will allow you to see if you made any real progress since the last period. It will give you perspective on what you're actually accomplishing rather than what you tell yourself you think you accomplished. Nothing makes it more real than writing it down. Your thoughts are usually very different from reality! So think of these reports as reality checks.
My own manager was out of the office for the week (I have a weekly status meeting) and so I didn't have to prep for the meeting that week. However, I went through with the exercise anyway and it was very revealing. Acting as though I had a real status meeting, I was able to see what was accomplished, and what was not. There were milestones that were achieved but on a smaller scale so I had to break those down into more fine-grained milestones. I then folded these back into my project plan, estimated durations and came up with new dates. I was also able to assess risks, and contact stakeholders for more information. That to me was amazing. It represented real pro-active project management. And I had no one breathing down my back to do this. PMs need to be real driving forces in getting projects done. This is something I'll talk about in a future post.
Saturday, September 18, 2010
Opening the Package
There's a brief parable I read once that described a beggar sitting on a wooden crate asking everyone who passed by for money. One day someone stopped and asked about the wooden crate he was sitting on. The beggar shrugged and said it was just his seat. The stranger said "So you never looked inside?" And so the beggar opened the crate and found a pile of gold.
That's it. Pretty simple. The lesson is obvious right? But how many times do we operate in our own lives like that beggar?
At work, we had a collection of development tickets that were being passed around from group to group looking for a home. No one wanted to own them and work on them. They looked like a hassle to deal with. Finally, I got them. What did I do? I clicked on each one and read the description. Then I made a few phone calls. 3 out of 5 of the tickets were obsolete and the other 2 were going to be resolved in a re-design of another project that was already in progress! Voila. Problem solved; it took only a 1/2 hour. The tickets were marked as deprecated and closed however these tickets had been passed around for several months!
Lesson: open the package. No one wanted to look inside! But once we did, the weight was lifted and it was painless...
This also happened in my personal life. I had bought a poster in California that was rolled up. I had to get it framed. I thought I knew the dimensions of the poster and that I needed to get it custom framed. I gave the dimensions to a framer and they gave me an insane price. I didn't act. The poster languished for 2 months before I took further action. This time, I actually unwrapped and unrolled the poster. And you know what?? The poster's dimensions were nowhere near the dimensions that I thought they were! They were much smaller and consequently cost much less to frame. Lesson: Open the package!
That's it. Pretty simple. The lesson is obvious right? But how many times do we operate in our own lives like that beggar?
At work, we had a collection of development tickets that were being passed around from group to group looking for a home. No one wanted to own them and work on them. They looked like a hassle to deal with. Finally, I got them. What did I do? I clicked on each one and read the description. Then I made a few phone calls. 3 out of 5 of the tickets were obsolete and the other 2 were going to be resolved in a re-design of another project that was already in progress! Voila. Problem solved; it took only a 1/2 hour. The tickets were marked as deprecated and closed however these tickets had been passed around for several months!
Lesson: open the package. No one wanted to look inside! But once we did, the weight was lifted and it was painless...
This also happened in my personal life. I had bought a poster in California that was rolled up. I had to get it framed. I thought I knew the dimensions of the poster and that I needed to get it custom framed. I gave the dimensions to a framer and they gave me an insane price. I didn't act. The poster languished for 2 months before I took further action. This time, I actually unwrapped and unrolled the poster. And you know what?? The poster's dimensions were nowhere near the dimensions that I thought they were! They were much smaller and consequently cost much less to frame. Lesson: Open the package!
Friday, August 13, 2010
Project Managers as Contractors is the WRONG way to go!
Everyone knows that project management in today's organizations is essential to business success. Without projects, you don't accomplish new business objectives. The discipline of project management is your best bet in reaching those objectives.
However, there seems to be an upward trend to hire project managers on a temporary basis to run these projects. I've seen it in my own organization and I've seen it with ex-colleagues who have gone on to take contractor positions in firms for the life of a project.
Indeed, the August issue of PMI's magazine PM Network has an item about this in The Buzz. Click here to read it.
One sentence says "...the temporary nature of projects makes them particularly good candidates for contract work".
This is quite true. It does seem like that...so what's the problem?
The problem is that effective project managers should be in place longer, much longer than just the life of the project. They are the ones that should be there permanently! PMs have more clout, more influence, and talk to more people than anyone else on the project. Their reach extends far and wide. Would you really want to lose all that after a project is finished?? If you find an effective PM, you keep 'em!
The ramp-up time for a new PM to be effective can be very long. For the PM to learn what makes their stakeholders tick, how to influence each and every one of them, to build relationships with them, along with the BAs, with the people doing the work, etc takes a very long time. The hub at the center of the wheel is difficult to replace.
So I've made my point about keeping PMs for the long-term. But what do you give up in this kind of environment where contracting is the new norm?
The solution is: The line positions that executes should be turned into contracting positions. Developers, architects, QA, support staff, for e.g.
If you have a strong PM & BA who are intimately familiar with what needs to be done, they can train new people to do exactly what they need them to do to accomplish the project goals. Especially with newcomers to the organization, it is important to get them off to the right foot and train them in the way you want things done. Then they will be able to deliver. We have a new QA person in Singapore who I will be training in our application. I will spend some late hours with him to get him up to speed but I will show him exactly what he needs to know. I don't mind doing this, because the payoff will be immense.
There is more of an impact on an organization's capability to deliver if you lose a PM vs. any other position. In my own case, I have been delivering in my space for nearly the last 2 years, and I have the confidence of the people around me that I am true to my word. This makes it easier for them to trust me and approve things. A new PM would have to build these relationships from scratch.
Furthermore, in today's agile world, no position is safe. If you're not advancing and continuing to build your skillset and your relationships, you're in danger of losing your job. Indeed, in the very same article, there is a quote, "When I hear people talk about temp versus permanent jobs, I laugh. The idea that any job is permanent has been well-proven not to be true."
So why should a developer who knows how to code a certain financial module (for instance) be so secure? Some people may think they have job security because only they know the module. However, if they're not performing, they should face the consequences, not be given free reign.
Plus, I'm willing to bet that a good developer or architect who comes fresh into a job and is given a mission (I need you to do x, y, and z and figure out how to do this) will see this as a challenge and figure out how to get the job done. Indeed, in my role as a BA on some projects, one of the pleasures I take is in coming fresh to a project and piecing together the puzzle of what needs to be done... This way, I start to own it.
However, there seems to be an upward trend to hire project managers on a temporary basis to run these projects. I've seen it in my own organization and I've seen it with ex-colleagues who have gone on to take contractor positions in firms for the life of a project.
Indeed, the August issue of PMI's magazine PM Network has an item about this in The Buzz. Click here to read it.
One sentence says "...the temporary nature of projects makes them particularly good candidates for contract work".
This is quite true. It does seem like that...so what's the problem?
The problem is that effective project managers should be in place longer, much longer than just the life of the project. They are the ones that should be there permanently! PMs have more clout, more influence, and talk to more people than anyone else on the project. Their reach extends far and wide. Would you really want to lose all that after a project is finished?? If you find an effective PM, you keep 'em!
The ramp-up time for a new PM to be effective can be very long. For the PM to learn what makes their stakeholders tick, how to influence each and every one of them, to build relationships with them, along with the BAs, with the people doing the work, etc takes a very long time. The hub at the center of the wheel is difficult to replace.
So I've made my point about keeping PMs for the long-term. But what do you give up in this kind of environment where contracting is the new norm?
The solution is: The line positions that executes should be turned into contracting positions. Developers, architects, QA, support staff, for e.g.
If you have a strong PM & BA who are intimately familiar with what needs to be done, they can train new people to do exactly what they need them to do to accomplish the project goals. Especially with newcomers to the organization, it is important to get them off to the right foot and train them in the way you want things done. Then they will be able to deliver. We have a new QA person in Singapore who I will be training in our application. I will spend some late hours with him to get him up to speed but I will show him exactly what he needs to know. I don't mind doing this, because the payoff will be immense.
There is more of an impact on an organization's capability to deliver if you lose a PM vs. any other position. In my own case, I have been delivering in my space for nearly the last 2 years, and I have the confidence of the people around me that I am true to my word. This makes it easier for them to trust me and approve things. A new PM would have to build these relationships from scratch.
Furthermore, in today's agile world, no position is safe. If you're not advancing and continuing to build your skillset and your relationships, you're in danger of losing your job. Indeed, in the very same article, there is a quote, "When I hear people talk about temp versus permanent jobs, I laugh. The idea that any job is permanent has been well-proven not to be true."
So why should a developer who knows how to code a certain financial module (for instance) be so secure? Some people may think they have job security because only they know the module. However, if they're not performing, they should face the consequences, not be given free reign.
Plus, I'm willing to bet that a good developer or architect who comes fresh into a job and is given a mission (I need you to do x, y, and z and figure out how to do this) will see this as a challenge and figure out how to get the job done. Indeed, in my role as a BA on some projects, one of the pleasures I take is in coming fresh to a project and piecing together the puzzle of what needs to be done... This way, I start to own it.
Sunday, August 8, 2010
The Invention of Process
Just finished reading "Rework"( Link to Rework )
As usual, class-A material from people who execute well. They have their act together...truly. I love the fact that their goal isn't to cater to the Fortune 500...they cater to the Fortune 5,000,000! The know where they stand and that's where their power comes from.
There's a chapter towards the back about Policy, and how in many instances, policies are "codified overreactions to situations that are unlikely to happen again." I totally agree!
This brings to mind a quote from a book that I read a long time ago on the making of the atom bomb. Edward Teller, a Nobel Prize winner and father of the hydrogen bomb, was advocating the use of a bomb on an asteroid as an experiment. Someone remarked, "If you've got a problem, Eddie's got a bomb!" Basically there were a lot of idle bomb experts sitting around after the war ended...
Well, the same holds true for process: If you've got a problem, [Insert Name here] down the hall has a process". The proliferation of processes is something you've got to watch out for. Several things can happen:
1. The process is actually too cumbersome, and people circumvent it.
2. It leads to a false sense of security that everyone is doing the right thing and that they're delivering quality software because all the i's are dotted and the t's are crossed.
3. Following the process doesn't mean you're even delivering anything of value. To be zen here, "Like the finger pointing at the moon, the finger is NOT the moon". Likewise, following a process is no guarantee of anything. It just means that some auditing team can catch you if you didn't upload some documents in a timely manner.
Ditto for templates...
As usual, class-A material from people who execute well. They have their act together...truly. I love the fact that their goal isn't to cater to the Fortune 500...they cater to the Fortune 5,000,000! The know where they stand and that's where their power comes from.
There's a chapter towards the back about Policy, and how in many instances, policies are "codified overreactions to situations that are unlikely to happen again." I totally agree!
This brings to mind a quote from a book that I read a long time ago on the making of the atom bomb. Edward Teller, a Nobel Prize winner and father of the hydrogen bomb, was advocating the use of a bomb on an asteroid as an experiment. Someone remarked, "If you've got a problem, Eddie's got a bomb!" Basically there were a lot of idle bomb experts sitting around after the war ended...
Well, the same holds true for process: If you've got a problem, [Insert Name here] down the hall has a process". The proliferation of processes is something you've got to watch out for. Several things can happen:
1. The process is actually too cumbersome, and people circumvent it.
2. It leads to a false sense of security that everyone is doing the right thing and that they're delivering quality software because all the i's are dotted and the t's are crossed.
3. Following the process doesn't mean you're even delivering anything of value. To be zen here, "Like the finger pointing at the moon, the finger is NOT the moon". Likewise, following a process is no guarantee of anything. It just means that some auditing team can catch you if you didn't upload some documents in a timely manner.
Ditto for templates...
Saturday, July 24, 2010
A Software release Today
Our team released some software this evening and it was a completely smooth process. Everything just worked! There were absolutely no hiccups. Everything that we expected to happen happened. Nothing unexpected happened, or if it did, we were prepared for it because we thought it might happen.
It is an indescribably satisfying feeling when things go according to plan! Now I know what Hannibal Smith meant when he said "I love it when a plan comes together".
To give some background, we had been planning this release for 2 weeks. I had an hour by hour runbook all set up. It was edited countless times & reviewed in several meetings. I also emailed everyone under the sun about the release.
The email was a point of contention. I felt that emailing EVERYONE would invite unnecessary questions about the release and possible interference by people who needn't be concerned but just wanted to put in their 2 cents; this was remedied by my mailing instead a select few who really did need to know AND by putting in full assurances about how much we tested this and that there were no issues in testing AND that we anticipate none after go-live AND how we will be in heightened alertness mode at business open. The result: "Thanks for letting me know." Problem solved. Lesson Learned: If you show confidence in your product, then people will believe. You just better deliver.
The beauty of being the PM is that all the work that I did in the planning, I witnessed the execution of at go-live. I didn't have much of a role in the release. I just asked a few questions but basically watched the event unfold. It was like being a movie director at the premiere of the movie.
It really does go to show that planning through a project pays dividends. There is a mentality of 'winging it' where some people pay lip service to planning, and might think through only a few things and leave the rest to chance. This experience has proven to me w/o a doubt that you can really execute according to a plan and be successful, as long as you have sufficient time to think things through.
It is an indescribably satisfying feeling when things go according to plan! Now I know what Hannibal Smith meant when he said "I love it when a plan comes together".
To give some background, we had been planning this release for 2 weeks. I had an hour by hour runbook all set up. It was edited countless times & reviewed in several meetings. I also emailed everyone under the sun about the release.
The email was a point of contention. I felt that emailing EVERYONE would invite unnecessary questions about the release and possible interference by people who needn't be concerned but just wanted to put in their 2 cents; this was remedied by my mailing instead a select few who really did need to know AND by putting in full assurances about how much we tested this and that there were no issues in testing AND that we anticipate none after go-live AND how we will be in heightened alertness mode at business open. The result: "Thanks for letting me know." Problem solved. Lesson Learned: If you show confidence in your product, then people will believe. You just better deliver.
The beauty of being the PM is that all the work that I did in the planning, I witnessed the execution of at go-live. I didn't have much of a role in the release. I just asked a few questions but basically watched the event unfold. It was like being a movie director at the premiere of the movie.
It really does go to show that planning through a project pays dividends. There is a mentality of 'winging it' where some people pay lip service to planning, and might think through only a few things and leave the rest to chance. This experience has proven to me w/o a doubt that you can really execute according to a plan and be successful, as long as you have sufficient time to think things through.
Monday, July 19, 2010
37 Signals Stuff
From the guys who created BaseCamp, here is a link to their book "Getting Real" on software development. Completely free on the web!
Getting Real
They also have a new book called Rework which I aim to read soon.
These guys are on the money with their stuff. Very readable, very applicable, very excellent!
For instance,
Click on the link above to read more...
Getting Real
They also have a new book called Rework which I aim to read soon.
These guys are on the money with their stuff. Very readable, very applicable, very excellent!
For instance,
Get something real up and running quickly
Running software is the best way to build momentum, rally your team, and flush out ideas that don't work. It should be your number one priority from day one.Click on the link above to read more...
Wednesday, June 16, 2010
Project Management Top 10 Problems
This isn't my list. But you can see this one here:
The Top 10 Mistakes
These all ring so true.
For instance, #2 :
The Top 10 Mistakes
These all ring so true.
For instance, #2 :
Believe that good scheduling software makes one a good project manager
Forget it! Like the post says, many people just get frustrated with Project thinking it will be like Excel and eventually give up.
There is a learning curve to this and it takes time (like with any new skill) to master it.
Friday, June 4, 2010
Project Plans are a personal matter!
Project Management is a very personal thing. It takes time to develop your own style and individual approach to the discipline. My recommendation is to try different things until you hit on something that works for you. And then share it. Despite all the standardization that the PMI has done with the discipline, you need to find ways to make it your own.
For instance, I hated using MS Project. I always had trouble with it, mostly because I never really dived in to learn it thoroughly.
So I went to an Excel spreadsheet to model project plans (which I stole from a colleague). I created a daily chart and color-coded it. I insert comments for each task and put down the # of hours I spent on each task. Voila! I have a written record of how I spend my time each day. I duplicated this sheet and made it weekly. So now I literally have a roadmap of all my releases for the next few months. I thought I was fine managing from Excel only.
However, I came back to MS Project because I realized I couldn't properly get good end-dates and that Excel won't calculate these and take into account weekends and holidays. In MS Project, I found that you can even adjust working hours! Then, as I got more and more interested, I realized the value of baselining and comparing actuals to the baseline and computing earned value (the holy grail! but still a work in progress).
It is not a simple thing to model real-life tasks in a software tool. But as I got familiar with Fixed Units, Fixed Duration, Fixed Work, & the various constraints & dependencies, this got easier. Now I'm in a position to more realistically model project tasks.
Now I flit back and forth b/w Excel & Project. Each gives me a unique way of managing my projects. I have a roadmap view, I have a log of how I spend my hours, I can see the progress of my project, etc. Someone could easily say that it takes too much time and I only need to use Project for everything. But I like this method. I feel I have more control and oversight of my domain. So you see, Project Management can be a very personal thing.
What's important is that you're able to manage. Managing by objective is key. If I give a due date for a project, it's important for me to constantly see if we're getting closer or we're slipping. That's all that matters. Not how pretty my project plan is or whether I use Excel, Project or a piece of paper.
For instance, I hated using MS Project. I always had trouble with it, mostly because I never really dived in to learn it thoroughly.
So I went to an Excel spreadsheet to model project plans (which I stole from a colleague). I created a daily chart and color-coded it. I insert comments for each task and put down the # of hours I spent on each task. Voila! I have a written record of how I spend my time each day. I duplicated this sheet and made it weekly. So now I literally have a roadmap of all my releases for the next few months. I thought I was fine managing from Excel only.
However, I came back to MS Project because I realized I couldn't properly get good end-dates and that Excel won't calculate these and take into account weekends and holidays. In MS Project, I found that you can even adjust working hours! Then, as I got more and more interested, I realized the value of baselining and comparing actuals to the baseline and computing earned value (the holy grail! but still a work in progress).
It is not a simple thing to model real-life tasks in a software tool. But as I got familiar with Fixed Units, Fixed Duration, Fixed Work, & the various constraints & dependencies, this got easier. Now I'm in a position to more realistically model project tasks.
Now I flit back and forth b/w Excel & Project. Each gives me a unique way of managing my projects. I have a roadmap view, I have a log of how I spend my hours, I can see the progress of my project, etc. Someone could easily say that it takes too much time and I only need to use Project for everything. But I like this method. I feel I have more control and oversight of my domain. So you see, Project Management can be a very personal thing.
What's important is that you're able to manage. Managing by objective is key. If I give a due date for a project, it's important for me to constantly see if we're getting closer or we're slipping. That's all that matters. Not how pretty my project plan is or whether I use Excel, Project or a piece of paper.
BA & PM Personalities
Bear with me on this one...It occurred recently to me (and it jives with personal experience) that:
- A PM should be pushy in order to get things moving and done
- A BA should be inquisitive and customer-focused
- A PM who is not so aggressive and who wants to gain consensus and make things right before commencing on a project, you might wait a loooong time before a project gets done.
- A BA who is pushy & aggressive is the most dangerous; they can really throw your project off because the BA may not gather all the details necessary to do a thorough analysis, does not listen to all the nuances and communications a stakeholder emits; s/he may not communicate all the details to the development team because they're off to the next project, etc.
Tuesday, May 11, 2010
Saturday, May 1, 2010
Risk in Project Management
I want to talk about risk in IT projects.
I don't feel we do a good enough job assessing risk and constantly staying on top of it.
Why?
IT Project Managers are under enormous pressure to deliver so looking only at the sunny day scenarios gives them a sense of optimism. Dates are then promised based on this scenario and everything is done to make that date. Risks are ignored, hoping they'll go away. Turning a blind eye is easier and then throwing your hands in the air is the final resort when the realization hits that there's no way you're going to make that date.
The nature of risk is that it's neither good nor bad. It just is. And it always exists. Hence it needs to be managed. Ignoring risk imperils projects, plain & simple. Another aspect of risk and more important, is that it constantly changes. Staffing changes can occur -> Risk occurs. A project can move from the requirements stage to the design change -> Risk occurs. In fact, every single day a new risk can reveal itself. Therefore, it is important to be constantly assessing for risk.
In simple terms, managing risk basically means staying on top of your project. You just can't do all your planning, baselining, draw your Gantt charts and say "GO!". After you put the ball in motion you have to watch where it goes constantly and re-adjust yourself, and your team (Tennis analogy anyone?)
So the first piece is to constantly monitor risk. That part requires vigilance for the duration of the project. You can do this via using checklists, talking to people, going to training, asking questions, etc. The 2nd and most often-neglected piece is to mitigate the risk. Identifying risks is not enough. Sometimes a risk makes itself apparent to you and everyone else and if it actually does occur, people tend to throw their hands in the air and complain and the project fails to move forward until it gets escalated. Someone from high on up chimes in and then the project starts to move again.
This is bad. Your boss or boss's boss shouldn't be managing your project.
The key is to assess the risk earlier and have a mitigating plan in place to deal with the risk. That way, if the risk actually does occur, you can follow the plan. Remember: to fail to plan is to plan to fail.
I find that there's not a lot of mitigation planning going on. Risks are usually left unattended. I've done this personally. I hadn't even realized I was doing this until some recent experiences have burned me.
Mitigation of risks is an extra step after identifying the risk and requires further research and thought. You need to reach out to others for help to see what can be done, who can act as backup, etc. It all seems like extra work beyond the actual work needed to get the project done. Perhaps this is why it is neglected. But it is absolutely crucial to do.
Overworked and juggling too many projects? That is a risk. Some projects need a dedicated Project Manager to see them through. Identify that as a risk and tell your boss or PMO. If they are made aware of it, they can remedy it.
More later...
I don't feel we do a good enough job assessing risk and constantly staying on top of it.
Why?
IT Project Managers are under enormous pressure to deliver so looking only at the sunny day scenarios gives them a sense of optimism. Dates are then promised based on this scenario and everything is done to make that date. Risks are ignored, hoping they'll go away. Turning a blind eye is easier and then throwing your hands in the air is the final resort when the realization hits that there's no way you're going to make that date.
The nature of risk is that it's neither good nor bad. It just is. And it always exists. Hence it needs to be managed. Ignoring risk imperils projects, plain & simple. Another aspect of risk and more important, is that it constantly changes. Staffing changes can occur -> Risk occurs. A project can move from the requirements stage to the design change -> Risk occurs. In fact, every single day a new risk can reveal itself. Therefore, it is important to be constantly assessing for risk.
In simple terms, managing risk basically means staying on top of your project. You just can't do all your planning, baselining, draw your Gantt charts and say "GO!". After you put the ball in motion you have to watch where it goes constantly and re-adjust yourself, and your team (Tennis analogy anyone?)
So the first piece is to constantly monitor risk. That part requires vigilance for the duration of the project. You can do this via using checklists, talking to people, going to training, asking questions, etc. The 2nd and most often-neglected piece is to mitigate the risk. Identifying risks is not enough. Sometimes a risk makes itself apparent to you and everyone else and if it actually does occur, people tend to throw their hands in the air and complain and the project fails to move forward until it gets escalated. Someone from high on up chimes in and then the project starts to move again.
This is bad. Your boss or boss's boss shouldn't be managing your project.
The key is to assess the risk earlier and have a mitigating plan in place to deal with the risk. That way, if the risk actually does occur, you can follow the plan. Remember: to fail to plan is to plan to fail.
I find that there's not a lot of mitigation planning going on. Risks are usually left unattended. I've done this personally. I hadn't even realized I was doing this until some recent experiences have burned me.
Mitigation of risks is an extra step after identifying the risk and requires further research and thought. You need to reach out to others for help to see what can be done, who can act as backup, etc. It all seems like extra work beyond the actual work needed to get the project done. Perhaps this is why it is neglected. But it is absolutely crucial to do.
Overworked and juggling too many projects? That is a risk. Some projects need a dedicated Project Manager to see them through. Identify that as a risk and tell your boss or PMO. If they are made aware of it, they can remedy it.
More later...
Tuesday, March 9, 2010
A quote on leadership
I love this quote on leadership by Lao Tzu, the founder of Taoism:
A leader is best when people barely know he exists, not so good when people obey and acclaim him, worse when they despise him....But of a good leader who talks little when his work is done, his aim fulfilled, they will say, "We did it ourselves."
A leader is best when people barely know he exists, not so good when people obey and acclaim him, worse when they despise him....But of a good leader who talks little when his work is done, his aim fulfilled, they will say, "We did it ourselves."
Saturday, March 6, 2010
Plugging In
What I mean by 'plugging in' is the ability to deliver needed capabilities as a project evolves over time.
For instance, I was assigned as a QA resource on a project which is what the manager on the project felt he needed. It soon turned out that what was really needed was an env manager to sort out issues currently experienced in UAT by outside users. So I straightened that out. Then I started sending out emails about the resolution of those issues daily. Then we got out of firefighting mode.
We've been able to move forward but now other issues have cropped up: we decreased the scope of our release but the other groups weren't notified so a change in the strategy was needed. I made sure this happened.
So now I'm communicating daily with all stakeholders about the status of the project. Sounds like what a PM does eh?
In addition, as those things get sorted out, I am actually doing some QA on the side and noticing things that are off-kilter. I'm communicating these to the dev team for fixes.
So what I am trying to communicate here is 'plugging in': the ability to fill in gaps as they arise. So I'm doing PM & QA/UAT and Env mgmt. The project takes a life of its own and as usual, we are short on resources. I can scream that I was only assigned to do QA and that I shouldn't be doing anything else, but I choose to engage on all levels and move the project along by seeing what needs to be done and doing it.
What it really takes to make it as a PM or BA in this industry is to be a generalist with a passion for learning. To speak with colleagues on the phone an ocean away whom I'll most likely never meet and to understand their pain from their point of view (netmeeting, webex anyone?) and then to demonstrate that pain to an SME who knows how to fix it. This is how I plug in. The SME may not be able to talk directly to the user because of time-zone issues or an inability to properly communicate, etc so I fill that gap.
It's taking care of the simple things: building the small bridges that most people overlook. I like to say that 'adding value' to something doesn't necessarily have to be a big-bang type of thing. You just see what needs to be done and do it. You see where things are being dropped and pick them up. Not rocket science, but it makes all the difference.
Eventually, people will think of you as a go-to person, someone who doesn't drop the ball, who gets things done. And nothing is better than that if you're worried about job security!
For instance, I was assigned as a QA resource on a project which is what the manager on the project felt he needed. It soon turned out that what was really needed was an env manager to sort out issues currently experienced in UAT by outside users. So I straightened that out. Then I started sending out emails about the resolution of those issues daily. Then we got out of firefighting mode.
We've been able to move forward but now other issues have cropped up: we decreased the scope of our release but the other groups weren't notified so a change in the strategy was needed. I made sure this happened.
So now I'm communicating daily with all stakeholders about the status of the project. Sounds like what a PM does eh?
In addition, as those things get sorted out, I am actually doing some QA on the side and noticing things that are off-kilter. I'm communicating these to the dev team for fixes.
So what I am trying to communicate here is 'plugging in': the ability to fill in gaps as they arise. So I'm doing PM & QA/UAT and Env mgmt. The project takes a life of its own and as usual, we are short on resources. I can scream that I was only assigned to do QA and that I shouldn't be doing anything else, but I choose to engage on all levels and move the project along by seeing what needs to be done and doing it.
What it really takes to make it as a PM or BA in this industry is to be a generalist with a passion for learning. To speak with colleagues on the phone an ocean away whom I'll most likely never meet and to understand their pain from their point of view (netmeeting, webex anyone?) and then to demonstrate that pain to an SME who knows how to fix it. This is how I plug in. The SME may not be able to talk directly to the user because of time-zone issues or an inability to properly communicate, etc so I fill that gap.
It's taking care of the simple things: building the small bridges that most people overlook. I like to say that 'adding value' to something doesn't necessarily have to be a big-bang type of thing. You just see what needs to be done and do it. You see where things are being dropped and pick them up. Not rocket science, but it makes all the difference.
Eventually, people will think of you as a go-to person, someone who doesn't drop the ball, who gets things done. And nothing is better than that if you're worried about job security!
Saturday, February 27, 2010
The giving of thanks
We recently had a change in management in our group and we have a new head boss. He's already been here a few weeks & is based in London. He came to NY recently and I met him as he did his rounds. That same day, this project I was put on in the last 2 weeks got escalated to him because the stakeholders weren't seeing any progress. This is the highest priority project we have right now and is already late. I got put on the project because I have an excellent track record in QA (which is *yet* another hat I've been wearing in the last year! More on that some other time).
Long story short, the same day I met him, he must have come to my cube about 5 or 6 times to get status updates! There was a quirk in the system that wasn't allowing proper comparison of BEFORE and AFTER files, so the users couldn't compare accurately.
In order to debug this thing, I pulled in resources from North Carolina, India (I called the guy at 6 AM and had him on the phone until 12pm which is 11pm his time), Houston and NY all to figure out this quirk. It was intense and I put in a lot of hours. We never figured out why it was failing but we instead devised another test procedure that was acceptable to the stakeholders.
I've also been placed in charge of all status updates to the stakeholders, so I sent out regular communications to them giving the latest status. I made sure these emails were clear, and detailed who was responsible for what. We steadily made progress and have nearly cleared the entire list of issues.
My boss sent me a note of thanks after each one with things like:
Can you believe the impact of one line like that ? It's indescribably awesome! These are emails I will stow away in my personal folder that I can come back to if I want a lift or to show off (I sent one to my Dad!).
Lessons Learned:
Long story short, the same day I met him, he must have come to my cube about 5 or 6 times to get status updates! There was a quirk in the system that wasn't allowing proper comparison of BEFORE and AFTER files, so the users couldn't compare accurately.
In order to debug this thing, I pulled in resources from North Carolina, India (I called the guy at 6 AM and had him on the phone until 12pm which is 11pm his time), Houston and NY all to figure out this quirk. It was intense and I put in a lot of hours. We never figured out why it was failing but we instead devised another test procedure that was acceptable to the stakeholders.
I've also been placed in charge of all status updates to the stakeholders, so I sent out regular communications to them giving the latest status. I made sure these emails were clear, and detailed who was responsible for what. We steadily made progress and have nearly cleared the entire list of issues.
My boss sent me a note of thanks after each one with things like:
- "Excellent work"
- "Awesome work. Push this one over the line"
- "You have taken ownership and this is exactly what I expect of people to do."
Can you believe the impact of one line like that ? It's indescribably awesome! These are emails I will stow away in my personal folder that I can come back to if I want a lift or to show off (I sent one to my Dad!).
Lessons Learned:
- Why be stingy about thanks? Some people don't have it in their nature to be effusive but that's not what's even required. A simple note of recognition can go a long way.
- Engagement, engagement, engagement! This guy was after me for updates and sending out emails to the stakeholders keeping them informed. He knew that the reason stakeholders escalated to him in the first place is that they were in the dark about the project and they felt nothing was being done. The first thing he stressed to me was to keep them engaged, and that is what I started to do. The cool thing is that he did it by his own example: he engaged me! He's the one that kept coming by, called me and IM'd me. So I became that way! Modeling the behaviors you want to see in others...how novel!
- Test the heck out of something. and test it smartly and efficiently. My belief is to test the software so well that you should be aware of any issues before you go into production. And then either resolve those issues or have workarounds. You don't want to go into production and then wind up seeing a problem you've never seen before. Preparation is key. Granted, there are times when something unexpected will happen and we have to deal with it on the fly. But this is rare and my preference is not to deal with the rare. Why spend a dollar on a 10 cent problem?
- Ideally, there shouldn't be any need for 'heroes': You know that special go-to person on your team who knows the system inside out and can solve your problems in a pinch. Things should never get that bad. I should have all issues worked out before I go to production and whatever issues there are should be transitioned to the support team so they know how to deal with it. I prefer saying instead that "everyone can be a hero!" and everyone can be if they all perform their roles to the utmost, don't drop things and take an active interest.
Where the heck have I been?
Well, I've taken quite the break there! Where have I been? I'm still at the same firm, just extremely busy. And plus, I just saw "Julie & Julia" and it brought back to my mind this blog. I've also been soaking in a lot of new experiences. In a way, I feel I've graduated. Joining my 'new' group (in late 2008) after my last BA position was like being hazed. It was like going from the minor leagues to the pros. We have to handle IT for all groups like Front Office (traders), risk, product control, operations, financial accting etc. I became a PM in the Architecture arena and I had to manage database migrations, and upgrades of various software components: work that could only be done on weekends and evenings and in a timely, controlled manner with lots of testing beforehand. It was anything unlike I had done before.
What was different?
What was different?
- As a BA I was responsible for only one part of the project and getting that right. As a PM, I am responsible for everything. Talk about pressure. And especially on projects where the DB better be back up on Sunday night (Monday AM in Asia)
- I had to get people to do things; I am not an official manager. No one reported to me. I had to keep pushing. There was no time to sit still and coast after I got one thing done. There was always something else to look at. PMs can never sit still!
- I find a satisfaction in being a PM that I don't know if I had being a BA. Not to say that one is better than the other. But there is something to be said for utter and complete accountability and responsibility of a project from start to finish. It all lies with you. You make or break the project.
Subscribe to:
Posts (Atom)