This is undoubtedly the hardest post I have ever written. I hope I never have a reason to say that again, either.
A couple of days ago, I got an email at work. It was from Mrs Q at home.
"We need to talk..."
Now usually when she says that, I've done something wrong and she wants to lecture me about it. This time, though, my conscience clear, I called her to find out what was up.
"I only sent you that so that I would have the courage to talk to you later," she said.
Now I was really worried.
That night she asked me for a divorce.
We spent the night talking and crying. At 3:30 a.m., we sort of ran out of things to say and she fell asleep beside me. I dosed, but only fitfully until the alarm went off at 6.
I drove into work as usual, fighting the traffic on auto-pilot, on roads covered with a dusting of slushy snow. When I arrived, I parked the car, got out, walked out of the parking garage, and realised that I couldn't do it. I couldn't go into the office and pretend that all was well, that I could concentrate on Gantt charts, requirements specifications, and conversations about mips, Websphere, DB2 and DASD. I just couldn't. So I got back in my car and drove home; I had nowhere else to go.
I am still in shock. Why didn't I see that coming? What could I have done differently to prevent it from getting this far? What was I going to do now?
Fortunately, she is not being vindictive, and in the 48 hours since her bombshell landed, we have yet to utter an angry word at each other. There are still a million questions to be answered, and no doubt more tears to be shed, but our beloved son has taken the news better than we could have hoped. So far.
Tomorrow, they move out, since junior can't stay with me during the day. I plan to take one more day off to get my head straight, and I will go into the office on Saturday to clear my Inbox and catch up on what's been happening. On Monday, then, I will try to get back into the routine and carry on with my life.
Because life must, somehow, go on.
Thursday, January 25, 2007
Friday, January 19, 2007
Building the project team - postscript
In my last post, I suggested never under-estimating the work to be done in a project. Ensuring I followed my own advice, I have been trying to secure the services of a dedicated configuration manager - someone who can control the hundreds of individual software components that will be written or amended (perhaps many times) over the course of this project. Someone who can ensure that every last one is correctly allocated, signed out, signed back in, and included in each of the migration packages through testing and finally into production. It's an important role.
On Monday, it was mentioned that Mike was available soon, since his contract was due to end in a couple of weeks time. I immediately asked that he be assigned to my project.
"Ah!" said the HR guy, "we should first look to see if there is a permanent staff member who could fill the role".
"Okay, like who?" I replied, knowing that no-one with a career at the company would settle for that kind of job. It's the sort of thing only contractors specialise in.
"Well, Ray could do it; he's free at the moment".
I didn't know Ray, so we arranged for me to talk to his line manager, then yesterday I finally got to speak to Ray himself.
Not only did he not have anywhere near the level of experience I wanted, but he had no knowledge of the software he would be using, and had never done that kind of thing before. He also didn't fancy the idea.
Back to the drawing board. I went back to HR guy and said "Ray doesn't want the job, and he's not qualified anyway. Can I have Mike now?"
"Okay, fill in the usual form and I'll get it sorted".
Excellent, I thought, and quickly completed the form and emailed it.
Less than an hour later, came the reply :
"Sorry, but his current assignment manager has just renewed his contract and extended his assignment until July. What would you like us to do?"
Aaaaaarrrgggghhhh!!
On Monday, it was mentioned that Mike was available soon, since his contract was due to end in a couple of weeks time. I immediately asked that he be assigned to my project.
"Ah!" said the HR guy, "we should first look to see if there is a permanent staff member who could fill the role".
"Okay, like who?" I replied, knowing that no-one with a career at the company would settle for that kind of job. It's the sort of thing only contractors specialise in.
"Well, Ray could do it; he's free at the moment".
I didn't know Ray, so we arranged for me to talk to his line manager, then yesterday I finally got to speak to Ray himself.
Not only did he not have anywhere near the level of experience I wanted, but he had no knowledge of the software he would be using, and had never done that kind of thing before. He also didn't fancy the idea.
Back to the drawing board. I went back to HR guy and said "Ray doesn't want the job, and he's not qualified anyway. Can I have Mike now?"
"Okay, fill in the usual form and I'll get it sorted".
Excellent, I thought, and quickly completed the form and emailed it.
Less than an hour later, came the reply :
"Sorry, but his current assignment manager has just renewed his contract and extended his assignment until July. What would you like us to do?"
Aaaaaarrrgggghhhh!!
Saturday, January 13, 2007
Condor - Building the project team
Building a project team is never a simple thing. While there may be such a thing as the perfect team for any given project, there are always some constraints. Depending on your organisation, you may have a limited pool of people to choose from. You may only know some of the people available. Some may not have all the skills you need. You may not be able to recruit externally, or you may have to choose permanent staff over more highly-skilled contractors.
But whatever the constraints imposed on you, the process shold be the same. Below, I will list some of the typical traps people (including me) can - and have - fallen into, and how to avoid falling in in the first place.
Trap No. 1 - forgetting about the obscure tasks.
First, you need to know what type of resources you need, and how many of them. And in order to establish that, you need to go back to your original estimate. The estimate should have detailed all the elements of work you estimated were needed based on the user's requirements. Okay? You should then be able to determine the skill set required for each task - do you need web developers or mainframe developers? What about database specialists, testers, defect managers, configuration managers? List them all. Be very thorough about the skills you need each person to possess. List all your requirements, and check them with someone who has managed projects in that environment before. Don't overlook anything.
Trap No.2 - under-estimating your needs.
Second, for each set of skills (Java, Oracle, CoBOL, DB2, etc. etc.) you need to work out how many people you will need to accomplish each piece of work within the time available. So if you have a high-level estimate of 70 man-days, but you only have 6 weeks - 6*5=30 days - to complete the task, you will need 70/30 = 3 people (always round up!). Now, list each role you have to fill (if you need 3 Java developers, list 3 roles). It may sound like a lot of people, but trust me, you will probably need them, and it's better to have too many people than not enough! Well, there is one exception to that rule - if you absolutely, positively canNOT go over the agreed budget, you will have to allow more time, but usually the constraint is more about time than money.
Trap No.3 - unproductive people.
Third, you need to work out when you will need them. Check your project plan, if you have one. When does the analysis work start? The development? How about the testing? For each role listed, work out when you will need to get each person to start. Factor in the need to get them through the interview process and HR checks, if you are recruiting them from outside the company. Allow for time for them to get acquainted with the project background and requirements. And make sure they all have a desk, chair, PC, network access, security pass, and anything else new people always need before they can actually do any work.
Now you can start looking at who you can get to fill each role.
If, like me, you must first look within the ranks of the company's permanent staff, fine. But make sure your needs are detailed enough. If you specify you need someone with DB2 experience, that's what you will get - someone who has done the course and once read some SQL code. If you want someone who can do database design in his sleep, say so! But make sure you have a balance. Never ask for ten experts because they will be constantly arguing with each other about the finer points of Java Beans or whether SOAP or REST is the better web services approach. You need balance! Define the structure of your team, and specify who reports to whom.
It is at this point that you are likely to fall into :
Trap No.4 - the people no-one wants.
Permanent staff who are available immediately, are probably available for a reason - they are on 'the Bench'! They have been released from a previous project because they were not sufficiently skilled, unproductive, didn't fit in, or just downright lazy. So check out every person you are offered before accepting them. Ask another project manager if he/she would work with the people you have been offered. You may hear that Bill is fine under normal circumstances, but never leaves after 5 and can't function before his third cup of morning coffee. You may hear that Judy is a fantastic coder, but is a little slow, and does not react well to pressure. Bear in mind that no-one is perfect, and everyone has his/her weaknesses. Just make sure that you can live with the ones mentioned, and can make allowances and adjustments if needed. And don't be afraid to say No to HR if someone is not suitable.
If the people you need are not available, you will have to recruit externally. It is useful to ask HR about contractors who have worked there before. Most contractors do not leave because they are not good enough; they leave because the budget dried up or the project was cancelled. If a contractor who fits the bill has worked at your organisation before for a period of more than a year, or was renewed more than once, get 'em in! Their earlier experience with your systems will avoid a lengthy learning curve that is just unproductive time.
Now you should start to see your team come together. First the requirements analysts, then the designers, the developers next and so forth.
In an ideal world you will have time to get the team together for an off-site kick-off meeting, where you can bond and establish everyone's DISC or Belbin profiles and perhaps modify the balance of your team so that you have enough but not too many of every type of person and everyone gets along. But in the real world, you need to get started yesterday, and you need these people on board NOW!
The important thing to remember in all of this is - if you don't ask, you won't receive.
Project Management is all about the people you have to do the job, and if you don't have the right people, you are creating problems for youself later.
But whatever the constraints imposed on you, the process shold be the same. Below, I will list some of the typical traps people (including me) can - and have - fallen into, and how to avoid falling in in the first place.
Trap No. 1 - forgetting about the obscure tasks.
First, you need to know what type of resources you need, and how many of them. And in order to establish that, you need to go back to your original estimate. The estimate should have detailed all the elements of work you estimated were needed based on the user's requirements. Okay? You should then be able to determine the skill set required for each task - do you need web developers or mainframe developers? What about database specialists, testers, defect managers, configuration managers? List them all. Be very thorough about the skills you need each person to possess. List all your requirements, and check them with someone who has managed projects in that environment before. Don't overlook anything.
Trap No.2 - under-estimating your needs.
Second, for each set of skills (Java, Oracle, CoBOL, DB2, etc. etc.) you need to work out how many people you will need to accomplish each piece of work within the time available. So if you have a high-level estimate of 70 man-days, but you only have 6 weeks - 6*5=30 days - to complete the task, you will need 70/30 = 3 people (always round up!). Now, list each role you have to fill (if you need 3 Java developers, list 3 roles). It may sound like a lot of people, but trust me, you will probably need them, and it's better to have too many people than not enough! Well, there is one exception to that rule - if you absolutely, positively canNOT go over the agreed budget, you will have to allow more time, but usually the constraint is more about time than money.
Trap No.3 - unproductive people.
Third, you need to work out when you will need them. Check your project plan, if you have one. When does the analysis work start? The development? How about the testing? For each role listed, work out when you will need to get each person to start. Factor in the need to get them through the interview process and HR checks, if you are recruiting them from outside the company. Allow for time for them to get acquainted with the project background and requirements. And make sure they all have a desk, chair, PC, network access, security pass, and anything else new people always need before they can actually do any work.
Now you can start looking at who you can get to fill each role.
If, like me, you must first look within the ranks of the company's permanent staff, fine. But make sure your needs are detailed enough. If you specify you need someone with DB2 experience, that's what you will get - someone who has done the course and once read some SQL code. If you want someone who can do database design in his sleep, say so! But make sure you have a balance. Never ask for ten experts because they will be constantly arguing with each other about the finer points of Java Beans or whether SOAP or REST is the better web services approach. You need balance! Define the structure of your team, and specify who reports to whom.
It is at this point that you are likely to fall into :
Trap No.4 - the people no-one wants.
Permanent staff who are available immediately, are probably available for a reason - they are on 'the Bench'! They have been released from a previous project because they were not sufficiently skilled, unproductive, didn't fit in, or just downright lazy. So check out every person you are offered before accepting them. Ask another project manager if he/she would work with the people you have been offered. You may hear that Bill is fine under normal circumstances, but never leaves after 5 and can't function before his third cup of morning coffee. You may hear that Judy is a fantastic coder, but is a little slow, and does not react well to pressure. Bear in mind that no-one is perfect, and everyone has his/her weaknesses. Just make sure that you can live with the ones mentioned, and can make allowances and adjustments if needed. And don't be afraid to say No to HR if someone is not suitable.
If the people you need are not available, you will have to recruit externally. It is useful to ask HR about contractors who have worked there before. Most contractors do not leave because they are not good enough; they leave because the budget dried up or the project was cancelled. If a contractor who fits the bill has worked at your organisation before for a period of more than a year, or was renewed more than once, get 'em in! Their earlier experience with your systems will avoid a lengthy learning curve that is just unproductive time.
Now you should start to see your team come together. First the requirements analysts, then the designers, the developers next and so forth.
In an ideal world you will have time to get the team together for an off-site kick-off meeting, where you can bond and establish everyone's DISC or Belbin profiles and perhaps modify the balance of your team so that you have enough but not too many of every type of person and everyone gets along. But in the real world, you need to get started yesterday, and you need these people on board NOW!
The important thing to remember in all of this is - if you don't ask, you won't receive.
Project Management is all about the people you have to do the job, and if you don't have the right people, you are creating problems for youself later.
Wednesday, January 10, 2007
Resource-Budget reconciliation
The initial setup phase of a project is always the most exciting; but often it is also the most frantic. I have spent most of the past week securing the right resources I need for project Condor. It has been difficult because :
The last thing I did this afternoon was to try to reconcile the people assigned with the original effort and hence the project budget. When I plot out each persons effort across the project timeline and multiply that by their man-day rate, I get a figure approximately 230 man-days over the allocated budget. Ooops. So tomorrow, in between meetings, I am going to have to go back over everything again and check that the people I have asked for, and their allocated time and cost, fit within the available budget.
What fun:-(
It occurred to me during all this that I do not have a simple tool to do all of the following:
- I do not know enough about the detailed work to be done to know who best to assign it to
- I do not know enough about the people who work here to know who best to assign.
The last thing I did this afternoon was to try to reconcile the people assigned with the original effort and hence the project budget. When I plot out each persons effort across the project timeline and multiply that by their man-day rate, I get a figure approximately 230 man-days over the allocated budget. Ooops. So tomorrow, in between meetings, I am going to have to go back over everything again and check that the people I have asked for, and their allocated time and cost, fit within the available budget.
What fun:-(
It occurred to me during all this that I do not have a simple tool to do all of the following:
- specify my resource requirements
- allocate people to each role across the project timeline
- calculate the effort of each person (or group of people) and the total effort and cost.
Thursday, January 04, 2007
Year-end Appraisal
I came to the conclusion years ago that performance appraisals don't matter at all when it comes to getting the juicy jobs and moving up the corporate ladder, and nothing I heard yesterday during my end of year appraisal interview has changed my mind about that.
Where it does matter is in determining what you are paid.
The comments I got from my own line manager, and even some of my direct reports, was universally positive. No-one had any specific words of criticism, not even constructive ones. I honestly wish they did - it would have explained why on a scale of 1-5, I scored 3 on almost everything.
In other words, I did my job - no more, no less. And this, despite comments like "... exceeded my expectations, despite a challenging assignment...".
What galls me the most is that to qualify for a managerial bonus, you need to score an overall 4 or 5, but only a small percentage of the managerial pool can be given such a rating. In other words, you are constantly being compared to your peers and whoever plays the game the best, gets the money.
The game?
I am referring to the performance measurement 'game'. It requires intimate knowledge of the measures used by the organisation to assess it's staff, and ensuring that you identify specific, measurable and achievable goals against which you can then be measured. Then it's up to you to exceed those targets.
Without prior experience of how the system works, I had few specific objectives, and hence had insufficient evidence of what I had done well.
Lesson learned.
Where it does matter is in determining what you are paid.
The comments I got from my own line manager, and even some of my direct reports, was universally positive. No-one had any specific words of criticism, not even constructive ones. I honestly wish they did - it would have explained why on a scale of 1-5, I scored 3 on almost everything.
In other words, I did my job - no more, no less. And this, despite comments like "... exceeded my expectations, despite a challenging assignment...".
What galls me the most is that to qualify for a managerial bonus, you need to score an overall 4 or 5, but only a small percentage of the managerial pool can be given such a rating. In other words, you are constantly being compared to your peers and whoever plays the game the best, gets the money.
The game?
I am referring to the performance measurement 'game'. It requires intimate knowledge of the measures used by the organisation to assess it's staff, and ensuring that you identify specific, measurable and achievable goals against which you can then be measured. Then it's up to you to exceed those targets.
Without prior experience of how the system works, I had few specific objectives, and hence had insufficient evidence of what I had done well.
Lesson learned.
You can't do much without a team
Managing, by definition, is accomplishing things through other people. Managing a project requires primarily a plan and a team of people to accomplish the tasks that you have planned.
In my case, I have a plan (sort of), but no team.
You see, like any IT project I require people with specific skills and experience. All of the suitable people I have identified are currently busy with another project - most of them on the same one.
With the first deadline looming - completion of the high-level design by the end of January - I fear the project is already Amber.
In my case, I have a plan (sort of), but no team.
You see, like any IT project I require people with specific skills and experience. All of the suitable people I have identified are currently busy with another project - most of them on the same one.
With the first deadline looming - completion of the high-level design by the end of January - I fear the project is already Amber.
Tuesday, January 02, 2007
Resourcing requirements
After an uneventful and relaxing couple of weeks at home, the first day back at work in the New Year was greeted with enthusiasm. I was genuinely looking forward to going back to work today, although the start was delayed somewhat.
On New Year's eve, I took the car down to a local hand wash place, and while doing the interior someone managed to dislodge the rear-view mirror from it's mounting, or rather dislodge the mounting from the windscreen. With no time left to do anything about it before this morning, I dropped into my friendly neighbourhood dealership to see if they could help.
Nope. You see the windscreens come with the mirror attachment bonded to the glass, and they have no way of re-attaching it. But they could sell me a replacement windscreen.
Oh, how I laughed!
Next stop was Autoglass. Their staff was eager to help, and in just a few minutes had the mirror bonded back in place again; and didn't charge me a penny. Thanks again.
I still managed to get into the office by 9:30, though. and started the one process we most dread on returning from holidays - clearing out the Inbox. One hundred and seven e-mails later, I was able to get some real work done.
In my absence the boss has done some high-level resource planning - numbers only - and calculated that, at peak periods, we will need 30 people working full-time on this. I now need to turn the numbers into names, get the requests in, get the people on board, briefed and give them some work to do. First task is to get an application design completed by the end of the month.
To say this project is challenging would be an understatement. But I wouldn't want it any other way.
Tomorrow I have my year-end appraisal interview.
On New Year's eve, I took the car down to a local hand wash place, and while doing the interior someone managed to dislodge the rear-view mirror from it's mounting, or rather dislodge the mounting from the windscreen. With no time left to do anything about it before this morning, I dropped into my friendly neighbourhood dealership to see if they could help.
Nope. You see the windscreens come with the mirror attachment bonded to the glass, and they have no way of re-attaching it. But they could sell me a replacement windscreen.
Oh, how I laughed!
Next stop was Autoglass. Their staff was eager to help, and in just a few minutes had the mirror bonded back in place again; and didn't charge me a penny. Thanks again.
I still managed to get into the office by 9:30, though. and started the one process we most dread on returning from holidays - clearing out the Inbox. One hundred and seven e-mails later, I was able to get some real work done.
In my absence the boss has done some high-level resource planning - numbers only - and calculated that, at peak periods, we will need 30 people working full-time on this. I now need to turn the numbers into names, get the requests in, get the people on board, briefed and give them some work to do. First task is to get an application design completed by the end of the month.
To say this project is challenging would be an understatement. But I wouldn't want it any other way.
Tomorrow I have my year-end appraisal interview.
