It has been a manic few weeks! I have had a lot on my plate recently, personally as well as at work, and I have had little time for blogging. I hope, however, to start making amends with immediate effect.
Since my last post, things have actually been going rather well.
Because of the tight and (virtually) impregnable deadline to deliver project Condor, we are simultaneously completing the requirements analysis, writing the Functional Specification, compiling the Application Design and even writing some of the component specifications. Yes, all at the same time. That it appears to be working is due solely to the calibre of people we have assembled on the project team. Skilled and motivated, they are working long hours, but not crazy hours and it is paying dividends.
It's worth noting, however, that we could not have assembled this team had we not had the top priority that this project commands. When the CEO says, 'get it done', people tend to make sure they get it done.
We hope to get the Functional Specification signed off this week, and the App Design won't be far behind. The developers start coding on Monday, and we need to be in Test by mid-April. It's tight, but do-able.
Me? I'm almost on top of the world. If things carry on like this, it should go like clockwork. Famous last words!! We are bound to find a major problem as soon as we get into testing, or we (don't) get full end-to-end connectivity for the first time. The biggest problem we have at the moment is two business units who can't agree on what needs to be done. A dedicated workshop is being set up on Wednesday to discuss it and reach an agreement.
But so far, we are on track.
Showing posts with label Condor. Show all posts
Showing posts with label Condor. Show all posts
Monday, March 05, 2007
Saturday, February 10, 2007
Priority Projects
In an organisation that runs a lot of projects at any given time, it is important to prioritise those projects, so that key resources - both financial and human - can be directed to where they will have the most benefit.
As a project manager, there is nothing worse that being assigned to a large, costly project with a low priority. Everyone's focus is on the higher-priority projects, and when it comes to looking for experienced people to work on your project, they all get stolen by the PMs with the higher-priority projects. It sucks.
Condor has been good in that respect. The benefits are in the tens of millions and the CEO of the parent company himself has said "Make It So".
So when, a couple of weeks ago, I mentioned that one of the people I wanted had been assigned elsewhere, I played the 'priority' card. I escalated my request to senior management, and they assessed the relative priorities of the two projects. I got the man I wanted, and he starts on Monday.
Of course, this competition does not win you a lot of friends among your peers, and it also removes one possible excuse, should you fail to deliver the project. But, to be selfish, I don't care. The important thing for me is to have the priority (important, beneficial, high-profile) projects, and to have the tools (the people, time and money) to succeed.
Getting the priority that you need gets you halfway there.
As a project manager, there is nothing worse that being assigned to a large, costly project with a low priority. Everyone's focus is on the higher-priority projects, and when it comes to looking for experienced people to work on your project, they all get stolen by the PMs with the higher-priority projects. It sucks.
Condor has been good in that respect. The benefits are in the tens of millions and the CEO of the parent company himself has said "Make It So".
So when, a couple of weeks ago, I mentioned that one of the people I wanted had been assigned elsewhere, I played the 'priority' card. I escalated my request to senior management, and they assessed the relative priorities of the two projects. I got the man I wanted, and he starts on Monday.
Of course, this competition does not win you a lot of friends among your peers, and it also removes one possible excuse, should you fail to deliver the project. But, to be selfish, I don't care. The important thing for me is to have the priority (important, beneficial, high-profile) projects, and to have the tools (the people, time and money) to succeed.
Getting the priority that you need gets you halfway there.
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
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.
Saturday, December 09, 2006
Workplace Politics harming the project
Back in September, I alluded to the impact that politics was having on project Condor. That impact reached a peak yesterday.
The Parent Company (TPC) have spent the last few weeks gathering requirements. It has, truth be told, been quite successful. Representatives from the outsourcing company in India have shown themselves to be slightly ignorant of how our business operates, but their knowledge of Use Cases has been encouraging and really helpful.
The problem is that this requirements gathering exercise has focused purely on what Condor's front-end application will do. No attention has been paid to the back-end core systems. They have assumed that everything below the web services interface layer is within my scope.... but it isn't. I have been given - on more than one occasion - a strictly limited scope and instruction not to 'get mugged' by taking on additional work. Politics. I have twice been told that we do not want to take the blame when something goes wrong. Aaaaarrrrrgh!!!
When I expressed my concerns over the gap in scope, no-one took any notice. Until yesterday.
My boss and I were talking about this scope gap, when he wondered aloud who our Business Unit thought was paying for this stuff - them or TPC. So I phoned the lovely K and asked.
She replied that they were paying for all the changes necessary for the product to work. Heartened, I explained about my enforced limitations, and my concerns that significant areas of requirements had not been included in anyone's scope nor budget. She thanked me and immediately got on the phone to G, my boss's boss. Later that afternoon, he came upstairs to talk to me and my boss about the situation. It didn't take long to convince him that it was 'reasonable' to expect us to do that work, since the outsourcing company were not going to do it, and it was our system, after all.
The upshot of it all is that I now have most of what I wanted in the first place. It would have been nice to manage the entire project, but I will still be responsible for providing the core functionality required for launch.
Although the project is still highly commercially sensitive - hence my use of the Condor code-name (not the real one) - once it is launched to the public, I will be able to reveal my involvement. I can now enjoy my weekend, and look forward to my final 5 hectic days at work before the holiday break.
The Parent Company (TPC) have spent the last few weeks gathering requirements. It has, truth be told, been quite successful. Representatives from the outsourcing company in India have shown themselves to be slightly ignorant of how our business operates, but their knowledge of Use Cases has been encouraging and really helpful.
The problem is that this requirements gathering exercise has focused purely on what Condor's front-end application will do. No attention has been paid to the back-end core systems. They have assumed that everything below the web services interface layer is within my scope.... but it isn't. I have been given - on more than one occasion - a strictly limited scope and instruction not to 'get mugged' by taking on additional work. Politics. I have twice been told that we do not want to take the blame when something goes wrong. Aaaaarrrrrgh!!!
When I expressed my concerns over the gap in scope, no-one took any notice. Until yesterday.
My boss and I were talking about this scope gap, when he wondered aloud who our Business Unit thought was paying for this stuff - them or TPC. So I phoned the lovely K and asked.
She replied that they were paying for all the changes necessary for the product to work. Heartened, I explained about my enforced limitations, and my concerns that significant areas of requirements had not been included in anyone's scope nor budget. She thanked me and immediately got on the phone to G, my boss's boss. Later that afternoon, he came upstairs to talk to me and my boss about the situation. It didn't take long to convince him that it was 'reasonable' to expect us to do that work, since the outsourcing company were not going to do it, and it was our system, after all.
The upshot of it all is that I now have most of what I wanted in the first place. It would have been nice to manage the entire project, but I will still be responsible for providing the core functionality required for launch.
Although the project is still highly commercially sensitive - hence my use of the Condor code-name (not the real one) - once it is launched to the public, I will be able to reveal my involvement. I can now enjoy my weekend, and look forward to my final 5 hectic days at work before the holiday break.
Sunday, December 03, 2006
Specifying Requirements
Now that project Condor has begun, one of the first workstreams - and arguably the most important - is specifying the Business requirements. Normally, IT projects are only started once we receive a Requirements Specification from the business area, and we start the analysis process. Requirements are often incomplete, ambiguous, stated without context, duplicated or reflect a suggested solution rather than a business need.
It is an oft-quoted statistic that the later in the life-cycle of a project - any project - that errors are spotted and eliminated, the more costly it is to do so. To quote an extreme example, one error in a requirements specification spotted during User Acceptance Testing can require weeks and cost tens of thousands of pounds to rectify, but only a few minutes if spotted before the specification is baselined.
In order to have any chance of meeting the tight deadlines imposed on this project, I have arranged for an analyst to be assigned to the business team drawing up the requirements. The project team assigned other people as well, and set up dedicated office space where everyone could work together, and arranged a series of workshops to draw out requirements on specific topics before they were documented.
Specifying business requirements - or user requirements - is not a difficult thing to do, but it's also very easy to do it badly, and make the developer's job a nightmare. We are not always understood when we explain something verbally, but it's even more difficult to get the message across accurately when we have to write it down.
Here are 8 simple rules about good requirements. Whether you are someone who specifies requirements, or someone who receives them, make sure the Requirements Specification you end up with follows these principles, and your project will be off to a good start.
It is an oft-quoted statistic that the later in the life-cycle of a project - any project - that errors are spotted and eliminated, the more costly it is to do so. To quote an extreme example, one error in a requirements specification spotted during User Acceptance Testing can require weeks and cost tens of thousands of pounds to rectify, but only a few minutes if spotted before the specification is baselined.
In order to have any chance of meeting the tight deadlines imposed on this project, I have arranged for an analyst to be assigned to the business team drawing up the requirements. The project team assigned other people as well, and set up dedicated office space where everyone could work together, and arranged a series of workshops to draw out requirements on specific topics before they were documented.
Specifying business requirements - or user requirements - is not a difficult thing to do, but it's also very easy to do it badly, and make the developer's job a nightmare. We are not always understood when we explain something verbally, but it's even more difficult to get the message across accurately when we have to write it down.
Here are 8 simple rules about good requirements. Whether you are someone who specifies requirements, or someone who receives them, make sure the Requirements Specification you end up with follows these principles, and your project will be off to a good start.
- Source - Identify who originated the requirement, so that any queries can be addressed to the right person.
- User - Identify who will benefit from each requirement.
- Clear and concise - Eradicate any possible ambiguity.
- Unique - Eliminate duplication.
- Identifiable - Each requirement must have a reference to ensure traceability (see below).
- Prioritised - Each requirement must be assigned a priority to distinguish between the ones that are essential for the business case, and which are 'nice-to-have'. The MoSCoW method is widely used for this purpose and is easy to understand.
- Verifiable - It must be possible to verify, by inspection or testing, that a requirement has been met. If you cannot verify it, you should not be specifying it.
- Genuine - Specify the requirement, not a suggested solution.
Saturday, November 25, 2006
Condor approved !
My portion of project Condor - the mainframe back-end bit - was granted formal approval this week. Even better, since Condor is currently the only approved project planning to build and utilise web services, I have been given additional funding to implement whatever web services Condor requires.
My total budget is now £1.6 million - more than enough, I think. It should give me plenty of flexibility to not only design services specifically for Condor, but also services that the current web application can use. After all, that is the point of web services - re-use.
This is an exciting time. It's going to get really busy really quickly.
I need to build up two teams - one for the mainframe work and one for the web services work.
I need to create a detailed project plan, draft a Terms of Reference, establish a project Board, define a stakeholder map, and a million other things that a project requires just to start functioning.
I love this part of a project - it's exciting. It's all about possibilities, and nothing has gone wrong... yet.
My total budget is now £1.6 million - more than enough, I think. It should give me plenty of flexibility to not only design services specifically for Condor, but also services that the current web application can use. After all, that is the point of web services - re-use.
This is an exciting time. It's going to get really busy really quickly.
I need to build up two teams - one for the mainframe work and one for the web services work.
I need to create a detailed project plan, draft a Terms of Reference, establish a project Board, define a stakeholder map, and a million other things that a project requires just to start functioning.
I love this part of a project - it's exciting. It's all about possibilities, and nothing has gone wrong... yet.
Tuesday, November 14, 2006
Taking on the Load
I am currently being torn between the desire to take on as much of the Condor project work as I can get (I love a challenge), and the opposing need to limit our involvement to what can be achieved within the current budget and resource capability.
You see, ever since this project somehow acquired the target of a mid-2007 delivery date (I am still unsure how that happened), the focus has been on 'how can we deliver this quickly?'. It is no longer 'my' project, and I will be managing only a portion of it. Disappointing. It is also clear that, since our business area has the requirements, and our development team have the expertise, the key to rapid design and build is probably to utilise what has gone before as far as possible. I am therefore tempted to take on as much work as I can get away with, but I am under strict instructions to preserve the other projects on the portfolio. In other words, I can utilise only those people not already allocated to higher-priority projects.
You see my problem. To be fair, when I asked if I could expand my present scope and the number of resources assigned, provided it did not affect other projects, I was told that was fine, as long as TPC pay for it.
We must, however, be seen to make the maximum effort to meet this (frankly unrealistic) target. To that end, we need to come up with ways to make most efficient use of the standard project methodology, modifying things where necessary, and re-use as much of the current intellectual and software capital already in place. The current method - sorry, framework - assumes a waterfall approach to managing the phases of a project. A set of requirements is delivered by the Business, an application design is created, followed by an Infrastructure design, followed by build.... you get the picture.
We are going to have to adopt a more overlapping approach to things, specifying dependencies at a much lower level. I have already suggested that we adopt a JAD approach to the requirements definition phase. I envisage defining requirements categories, each being specified in parallel, but not wholly in isolation, with significant IT involvement, since the so-called business analysts don't actually have any analysis training.
We will also need to combine the design phases, producing application and infrastructure designs in parallel.
Any of you managers used to delivering software projects will recognise the challenges inherent in meeting a mid-2007 deadline with an estimated spend of £6m. We need to get a quite phenomenal 'burn-rate' to obtain that sort of productivity.
You see, ever since this project somehow acquired the target of a mid-2007 delivery date (I am still unsure how that happened), the focus has been on 'how can we deliver this quickly?'. It is no longer 'my' project, and I will be managing only a portion of it. Disappointing. It is also clear that, since our business area has the requirements, and our development team have the expertise, the key to rapid design and build is probably to utilise what has gone before as far as possible. I am therefore tempted to take on as much work as I can get away with, but I am under strict instructions to preserve the other projects on the portfolio. In other words, I can utilise only those people not already allocated to higher-priority projects.
You see my problem. To be fair, when I asked if I could expand my present scope and the number of resources assigned, provided it did not affect other projects, I was told that was fine, as long as TPC pay for it.
We must, however, be seen to make the maximum effort to meet this (frankly unrealistic) target. To that end, we need to come up with ways to make most efficient use of the standard project methodology, modifying things where necessary, and re-use as much of the current intellectual and software capital already in place. The current method - sorry, framework - assumes a waterfall approach to managing the phases of a project. A set of requirements is delivered by the Business, an application design is created, followed by an Infrastructure design, followed by build.... you get the picture.
We are going to have to adopt a more overlapping approach to things, specifying dependencies at a much lower level. I have already suggested that we adopt a JAD approach to the requirements definition phase. I envisage defining requirements categories, each being specified in parallel, but not wholly in isolation, with significant IT involvement, since the so-called business analysts don't actually have any analysis training.
We will also need to combine the design phases, producing application and infrastructure designs in parallel.
Any of you managers used to delivering software projects will recognise the challenges inherent in meeting a mid-2007 deadline with an estimated spend of £6m. We need to get a quite phenomenal 'burn-rate' to obtain that sort of productivity.
Saturday, November 11, 2006
Condor to be outsourced.
A workshop was held yesterday, the purpose of which was to work out an action plan for the next 30 days. Why 30 days? Well, that takes us to virtually the end of the year.
The new programme manager for Condor, E, said that in order to have even the remotest chance of getting this project implemented by mid-year, we need to have some requirements and some high-level designs by the end of this year. And he's right! So what do we need to to do achieve that?
The group identified several separate work streams - Requirements, Design, Testing, Business Operating Model, etc. A team leader was appointed to each, and other people allocated to each work stream according to who the group felt was best suited to performing the tasks identified in each. It's a decent enough approach. For me the biggest disappointment of the day was seeing representatives from an outsourcing company in India present. It is obvious that E has already made the decision to outsource a large amount of the development work.
The end of the meeting was by far the most revealing.
On a flip chart, someone drew a mini Gantt chart showing, against the project timeline, the major activities and milestones that we would need to hit to make the plan work. The level of overlap between activities made it obvious that, either we were simply not going to do it, or we were letting ourselves in for the mother of all managerial nightmares.
E finished up the meeting by saying that while it appeared as if the plan was... um... challenging, he was not prepared to go back to his boss and say it was not do-able, until the various work streams generated the estimates to prove it. Smart cookie. E is no fool, and is obviously a very experienced and competent manager. He is surrounding himself with people he trusts and who he knows can do the job.
The new programme manager for Condor, E, said that in order to have even the remotest chance of getting this project implemented by mid-year, we need to have some requirements and some high-level designs by the end of this year. And he's right! So what do we need to to do achieve that?
The group identified several separate work streams - Requirements, Design, Testing, Business Operating Model, etc. A team leader was appointed to each, and other people allocated to each work stream according to who the group felt was best suited to performing the tasks identified in each. It's a decent enough approach. For me the biggest disappointment of the day was seeing representatives from an outsourcing company in India present. It is obvious that E has already made the decision to outsource a large amount of the development work.
The end of the meeting was by far the most revealing.
On a flip chart, someone drew a mini Gantt chart showing, against the project timeline, the major activities and milestones that we would need to hit to make the plan work. The level of overlap between activities made it obvious that, either we were simply not going to do it, or we were letting ourselves in for the mother of all managerial nightmares.
E finished up the meeting by saying that while it appeared as if the plan was... um... challenging, he was not prepared to go back to his boss and say it was not do-able, until the various work streams generated the estimates to prove it. Smart cookie. E is no fool, and is obviously a very experienced and competent manager. He is surrounding himself with people he trusts and who he knows can do the job.
Thursday, November 09, 2006
Planning to Fail
When I posted (here and then here) that I was sceptical about the plan to deliver Condor in 6 months, it now appears that I was not the only one. At a meeting earlier this evening, it transpired that I am being instructed to limit our involvement in the project not only to protect the other projects on the portfolio - although there is an element of that in the mix - but also to limit the damage should the project fail.
It was even suggested that the web front-end component should be outsourced to India. This would have two benefits - relieving us of the need to resource it ourselves, and providing someone else to blame when the plan slips.
The fact that The Parent Company is willing to fund and resource a large part of this project means that our part of the company is happy for them to go ahead and get their noses bloodied, while we merrily go on delivering the other planned projects on our workstack.
Why can they not create a realistic and workable plan to succeed, rather than playing political games to limit the damage of failure? Perhaps the fallout from the US mid-term elections has had consequences far beyond the boundaries of the United States, in ways no-one predicted.
This project is starting to get a distinctly nasty smell attached to it.
It is situations like this that make me glad I am publishing these comments anonymously.
It was even suggested that the web front-end component should be outsourced to India. This would have two benefits - relieving us of the need to resource it ourselves, and providing someone else to blame when the plan slips.
The fact that The Parent Company is willing to fund and resource a large part of this project means that our part of the company is happy for them to go ahead and get their noses bloodied, while we merrily go on delivering the other planned projects on our workstack.
Why can they not create a realistic and workable plan to succeed, rather than playing political games to limit the damage of failure? Perhaps the fallout from the US mid-term elections has had consequences far beyond the boundaries of the United States, in ways no-one predicted.
This project is starting to get a distinctly nasty smell attached to it.
It is situations like this that make me glad I am publishing these comments anonymously.
Wednesday, October 25, 2006
Feeling guilty
In Monday's post about R's resignation, I neglected to mention that he asked me to keep the information to myself. Well, yesterday I might have accidentally let something slip on the subject to my boss, who, by coincidence, was having lunch with one of the Business managers.
It appears that he told the Business manager, who told his boss - and the rest of their office, and the news reached the ears of the guy in charge of the business-end of the Condor project. He is now very unhappy that R is still in the office, given his knowledge of commercially sensitive information about the project.
I am feeling really guilty about it, but there's not much I can do about it now. I don't see why he should go on 'gardening leave', since he is not going to learn anything new about it between now and the day his notice is up and he leaves for good. On the contrary, he might be able to assist us further.
I hate feeling guilty. I don't screw up often, but when I do, it doesn't feel nice.
It appears that he told the Business manager, who told his boss - and the rest of their office, and the news reached the ears of the guy in charge of the business-end of the Condor project. He is now very unhappy that R is still in the office, given his knowledge of commercially sensitive information about the project.
I am feeling really guilty about it, but there's not much I can do about it now. I don't see why he should go on 'gardening leave', since he is not going to learn anything new about it between now and the day his notice is up and he leaves for good. On the contrary, he might be able to assist us further.
I hate feeling guilty. I don't screw up often, but when I do, it doesn't feel nice.
Monday, October 23, 2006
Traitor
The secrecy with which the initial investigations into the feasibility of project Condor was conducted has had an unwanted side-effect. Now that we are, of necessity, getting more people involved to get the project formally incepted, we are spending more time re-hashing the same old assumptions, conclusions and ideas as we did a couple of months ago.
Today, for instance, we spent about four and a half hours bringing just four people up to date with the high-level design we had arrived at via 6 weeks of discussion and investigation. Oh well. Whatever gets us to the start line, I suppose.
On a different note, my good friend R, the architect behind the initial idea, the guy who initiated the feasibility study (although I had to expand the scope) in the first place, the guy who has so supported me through the whole exercise, has resigned. Yep, he handed in his notice on Friday. Considering his strategic role in the company, he may just be asked to leave sooner rather than later, too. Leaving me to run with it alone. More or less.
I feel betrayed.
But I wish him all the best in his new venture.
Today, for instance, we spent about four and a half hours bringing just four people up to date with the high-level design we had arrived at via 6 weeks of discussion and investigation. Oh well. Whatever gets us to the start line, I suppose.
On a different note, my good friend R, the architect behind the initial idea, the guy who initiated the feasibility study (although I had to expand the scope) in the first place, the guy who has so supported me through the whole exercise, has resigned. Yep, he handed in his notice on Friday. Considering his strategic role in the company, he may just be asked to leave sooner rather than later, too. Leaving me to run with it alone. More or less.
I feel betrayed.
But I wish him all the best in his new venture.
Thursday, October 19, 2006
Dilemma
I just looked up that word here and here. Both define the word as primarily a choice between two equally unfavourable options. But I might have to choose between two equally favourable options. Let me explain.
Having had three separate meetings today on the subject of Project Condor, it appears as if it's gathering momentum fast. There is not only a huge desire among senior management for this, but it has now also been given a candidate slot for May 2007 implementation. You heard it here first. The fact that I don't believe we can deliver as early as May remains to be believed among those that count. There is a workshop on Tuesday afternoon to start discussing the candidate projects for the May release, and I am invited to discuss Condor. Excellent.
In the meantime, my name was mentioned by my good friend R, with whom I have been closely working on Condor, to a programme manager who apparently has a piece of work that he a) is finding hard to accurately define, and b) needs someone to pick up and run with. R thought I could help him out.
So on Tuesday, I met with him (let's call him A) to discuss this piece of work. It turns out to be the rollout of a Service Oriented Architecture (SOA) across the organisation. The scope has not yet been defined and it has thus far been seen as phase 2 of the SOA adoption project, which delivers the framework, standards and development toolset for a service-oriented architecture.
Now, as we all know, a project has a definite start and end and a clear objective, and therefore cannot be ongoing by definition.
He concluded the meeting by asking about my availability, making it clear that the job was mine if I wanted it.
Hell, yes! You see, it would entail forming a more-or-less permanent team (something I have wanted for years), to become a 'centre of excellence' for web services and service-oriented architecture. It would require more man-management, but a lot less of the administrative cr*p that goes with pure project management. An ideal mix of all the best parts of IT management with very few of the worst parts. Fantastic.
And therein lies the dilemma (or whatever is the choice between two equally favourable options). Do I stick with Condor and deliver the IT components of a new Brand with national exposure (it's like being able to say I managed the project to developed Amazon.com), or do I take on the SOA adoption piece?
I almost certainly cannot do both (although that would be ideal, because of the need to run both pieces of work more or less simultaneously.
Please let me know what you would do and why.
Having had three separate meetings today on the subject of Project Condor, it appears as if it's gathering momentum fast. There is not only a huge desire among senior management for this, but it has now also been given a candidate slot for May 2007 implementation. You heard it here first. The fact that I don't believe we can deliver as early as May remains to be believed among those that count. There is a workshop on Tuesday afternoon to start discussing the candidate projects for the May release, and I am invited to discuss Condor. Excellent.
In the meantime, my name was mentioned by my good friend R, with whom I have been closely working on Condor, to a programme manager who apparently has a piece of work that he a) is finding hard to accurately define, and b) needs someone to pick up and run with. R thought I could help him out.
So on Tuesday, I met with him (let's call him A) to discuss this piece of work. It turns out to be the rollout of a Service Oriented Architecture (SOA) across the organisation. The scope has not yet been defined and it has thus far been seen as phase 2 of the SOA adoption project, which delivers the framework, standards and development toolset for a service-oriented architecture.
Now, as we all know, a project has a definite start and end and a clear objective, and therefore cannot be ongoing by definition.
He concluded the meeting by asking about my availability, making it clear that the job was mine if I wanted it.
Hell, yes! You see, it would entail forming a more-or-less permanent team (something I have wanted for years), to become a 'centre of excellence' for web services and service-oriented architecture. It would require more man-management, but a lot less of the administrative cr*p that goes with pure project management. An ideal mix of all the best parts of IT management with very few of the worst parts. Fantastic.
And therein lies the dilemma (or whatever is the choice between two equally favourable options). Do I stick with Condor and deliver the IT components of a new Brand with national exposure (it's like being able to say I managed the project to developed Amazon.com), or do I take on the SOA adoption piece?
I almost certainly cannot do both (although that would be ideal, because of the need to run both pieces of work more or less simultaneously.
Please let me know what you would do and why.
Monday, October 16, 2006
Unlikely
I am still trying to work out how someone got to the figures of 6 million pounds / 6 months to deliver project Condor. The best plan I can come up with has us implementing in October '07, regardless of who does the work. And that assumes that the green light is given next week and work starts on Requirements definition immediately.
It's unlikely to say the least.
More disturbing is that I was left off of the distribution list for the meeting held last week, despite the fact that I have an action. Is that a hint?
I am pulling together a list of the deliverables, and some assumptions, but I am battling to work out how to specify milestones for just a small part of the work. It's unrealistic without seeing them in the broader context of the overall plan. Which I am obviously disputing. I am debating with myself whether I should distribute the entire MS Project plan I have, showing all the relevant high-level tasks, and let everyone pick the bones out of it.
I drove home this afternoon in melancholy mood. I get like this sometimes, but it rarely lasts long.
I'll be more chirpy soon. All should be resolved by Thursday.
It's unlikely to say the least.
More disturbing is that I was left off of the distribution list for the meeting held last week, despite the fact that I have an action. Is that a hint?
I am pulling together a list of the deliverables, and some assumptions, but I am battling to work out how to specify milestones for just a small part of the work. It's unrealistic without seeing them in the broader context of the overall plan. Which I am obviously disputing. I am debating with myself whether I should distribute the entire MS Project plan I have, showing all the relevant high-level tasks, and let everyone pick the bones out of it.
I drove home this afternoon in melancholy mood. I get like this sometimes, but it rarely lasts long.
I'll be more chirpy soon. All should be resolved by Thursday.
Saturday, October 14, 2006
Condor too heavy
It's been two weeks since my last post - criminal!
Actually, it's been a little hectic around here with the mother-in-law staying with us. Anyway, I have been back at work for a week, and what a week it has been.
In my absence, the report we wrote (or at least a synopsis thereof) has been sent all the way to the CEO. The reponse has been more or less what we expected - at 12 months work and costing around 8 million pounds, it's too expensive and will take too long.
While I was loafing at home, some additional work was apparently done to determine how much work could be stripped out, in order to make it quicker and cheaper to deliver. The new figures are six months and six million pounds (although that excludes capex). Say what???
I can find no evidence of how six months and around 2 million pounds has been cut from the estimate, and yet no-one seems too uncomfortable that we can deliver to those figures. I am aghast. I went so far as to speak to G, my boss's boss to tell him I don't believe it is achievable.
After an audio conference yesterday, it does appear, though, that in the grandiose halls of The Parent Company (TPC), significant weight is being applied to get this project off the ground. There were even suggestions that, since the basic infrastructure requirements are fairly clear already (albeit undocumented), someone can start work on the Infrastructure design. Without any Business Case having yet been completed! It is seen as a strategic revenue-generator, and looks to be given a very high priority relative to the rest of the portfolio. That in itself is A Good Thing, but I have two major concerns:
I just want a reasonable shot at it.
Actually, it's been a little hectic around here with the mother-in-law staying with us. Anyway, I have been back at work for a week, and what a week it has been.
In my absence, the report we wrote (or at least a synopsis thereof) has been sent all the way to the CEO. The reponse has been more or less what we expected - at 12 months work and costing around 8 million pounds, it's too expensive and will take too long.
While I was loafing at home, some additional work was apparently done to determine how much work could be stripped out, in order to make it quicker and cheaper to deliver. The new figures are six months and six million pounds (although that excludes capex). Say what???
I can find no evidence of how six months and around 2 million pounds has been cut from the estimate, and yet no-one seems too uncomfortable that we can deliver to those figures. I am aghast. I went so far as to speak to G, my boss's boss to tell him I don't believe it is achievable.
After an audio conference yesterday, it does appear, though, that in the grandiose halls of The Parent Company (TPC), significant weight is being applied to get this project off the ground. There were even suggestions that, since the basic infrastructure requirements are fairly clear already (albeit undocumented), someone can start work on the Infrastructure design. Without any Business Case having yet been completed! It is seen as a strategic revenue-generator, and looks to be given a very high priority relative to the rest of the portfolio. That in itself is A Good Thing, but I have two major concerns:
- that TPC insist on doing the majority of the work and with limited budget and time, develop a basic strategic product that doesn't actually meet the original requirements.
- that, even if I am allowed to put together a team to do a large part of the work (after all, it's our Business area that wants this project), I will be held to the 6 months, 6 million pound budget. I just do not think that is achievable without some VERY dodgy accounting - not something I am happy to do.
I just want a reasonable shot at it.
