User stories not enough on their own

I am starting a small project. It has a deadline of 28th July for go-live. I have a prioritized requirements list, and a complete, motivated and committed team. But I am really uneasy because we have yet to settle on a technical direction.

I have no idea which stories to select for the first timebox because what we deliver first depends on the technical strategy, which in turn dictates the estimates for some of the major stories.

We need to make a decision, and quickly!


Mobile

Mobile agility

Now that there is an iPhone app for (almost literally) everything, I have run out of excuses for not posting to this blog more regularly. So later this week I will take stock of where we were and post an item on Atern workshops.

Watch this space.

-- Post From My iPhone

Increment Planning

In an ideal world, all of the candidate user stories will be perfectly defined and understood, and all of the preparatory work will have been done by the business in advance. It is often the case, though, that there is not quite universal understanding of all the stories, and some clarification is required before the size of each can be estimated.

For my project, being a redesign of a part of our web site, the business have created mock-ups of what the new pages should look like, in some cases with HTML and CSS, which of course makes integrating them into the final solution that much easier, and more accurate. It is very worthwhile getting the business to provide a visual representation of the solution they want – it is an invaluable aid to understanding.

It is also very worthwhile discussing the candidate stories about a week in advance of the start of the Increment. My project plan showed timebox 4 (in Increment 1) finishing on the Wednesday, and timebox 5 (the first for Increment 2) starting on the Thursday. In reality, timebox 5 will have to kick-off a day of two later, to accommodate the story analysis and increment planning.

Representation from all key stakeholders is essential. We have a number of stories which generated some animated discussion between two different business areas. Resolving these discussions is essential to determining how the solution will be developed; without everyone’s active participation, there is a very real risk of developing the wrong solution.

Ensure you have enough time. Plan on a full day to get the most out of it.

It is essential that you do not get drawn into too much detail at this point. The objective is to ensure that everyone understands the requirements, and the stories for the first timebox can be selected. It is not meant to be a design discussion. If conversation starts getting bogged-down in detail, move on.

A facilitator helps enormously. Without a structure to it, these sessions can break down into mere discussions, with no direction or meaningful progress. Increment planning should have an agenda something like this :

• Introductions – make sure everyone on the project team is present and knows who everyone else is and their role, both on the project and in the meeting.
• Functional Overview – opportunity for the business to provide an overview (preferably visual) of the objectives of the Increment.
• Candidate Stories – the Business Ambassador presents each candidate story. Ensure that everyone present understands the requirement of each story – understanding how it will be delivered is not necessary at this stage.
• Estimation – generate estimates of the relative size and complexity of each story. This can be in ideal-days or in story points. I prefer story points, because it provides an objective measure of progress. These estimates are also essential to ensuring that there is sufficient ‘contingency’ available in the form of ‘could have’ stories.
• Prioritisation – MoSCoW prioritise each story according to its business benefit and contribution to the business vision.
• Selection – based on technical or business dependencies and priorities, select the user stories that will be delivered in the first timebox.

So, in summary:

• Get the Business to prepare their stories and any visual aids in advance
• Plan for a full-day session ahead of the actual Increment start date.
• Ensure all stakeholders are present, as well as the entire project team, including testers
• Get a neutral facilitator to run the session.
• Don’t get into any discussions about designing the solution. Just understand the requirements.

Increments and Timeboxes

Having divided the entire Prioritised Story List into three distinct Themes (or Increments in technical speak), we have just finished work on the first increment. Well, sort of. We have deployed the last of our stories into our test environment, but there are still some bugs outstanding, so we will be dedicating some time to fixing those over the next week or so before we put it live.

So we have now arrived at another Increment boundary and I have learned another lesson: Increment planning should be done in advance! Until yesterday, I was under the impression that we should ignore the second increment until we were finished with the first. But yesterday’s planning session was slow going. I also made the mistake of confusing it with a timebox kick-off, so I was expecting too much from the session.

It is therefore important to distinguish between an Increment Planning session (in which the candidate user stories are reviewed, clarified, understood, and prioritised), and a Timebox kick-off, in which the stories selected for development within the upcoming timebox are broken down into development tasks and estimated.

My next post will contain a few guidelines for conducting Increment Planning sessions.

Am I Agile by nature?

Traditional project management methods emphasise control. There are a myriad of processes and tools (with attendant templates) to impose control over the chaos that is typical of the average IT project.

Not least of these is the bizarre addiction to MS Project. I know few people who use it well, and even fewer who actually like using it. I hated it! Still do. A company I worked for until recently insisted that all projects use one of three templates (and had a department monitoring adherence - QA they called it!!). The different templates were intended to be used for different types or sizes of project, and differed in the number of standard tasks that were listed.

The problem with MS Project templates of course is the tailoring needed to make them fit the reality of the project you are planning. And in typical waterfall projects the plan tends to change on an all-too-frequent basis. I found myself having to manage the plan, rather than the project, because that was what the company expected of me. How unproductive is that?

I knew that there was a problem with this approach to project management - this management by template - I just didn’t know how to express it. In essence, it takes away our focus on the most important element of any project – the people. It forces managers to focus on the administration, the bureaucracy, the paperwork.

In our fairly extreme implementation of Agile practices, MS Project is not used at all. Our planning is done on two levels:

• How much overall work is there, how long will it take, and how many people are required?
• What detailed tasks are we going to work on within the next timebox (1-4 weeks)

Now that I am able to more simply monitor – not control – the task plan, I am utilising my time to better effect. I am more effective in leading the team forward, and I am happier as a result. Perhaps I was born an Agilist?

Agile Software development – high-level planning

As at the point described in my last post, we had created a pile of story cards, representing a Prioritised Requirements List (PRL). Each story had associated with it relative benefit to the business, a story-point estimate of relative size and complexity, and a MoSCoW-scale prioritisation, a DSDM concept.

Now, how are we going to deliver solutions to these requirements, and just as importantly, when?

Our first task was to group all of the user stories into ‘Themes’ of related requirements. This is so that we can decide what functionality can be released into Production together. In our case, requirements or features of particular parts of the site were grouped into Themes. Those stories referring to features of the new Home page went in Theme 1, those related to up-sell and Claims (did I mention we are an Insurance company) went in Theme 2, and those related to Amendments went in Theme 3. Generally speaking, Theme 1 should be the most important and deliver the biggest benefit, but in our case, although it does deliver business benefit in its own right, it is more an enabler for Theme 2, when the big benefit is realised.

Themes are also known as Increments or Releases. I am inclined to use the term Themes when referring to user stories with the Business, and Increments when talking to the technical guys, but the terms are largely interchangeable.

From what I have read so far, all Agile methods (XP, or eXtreme Programming, Scrum, DSDM, etc.) have in common the concept of working in short periods of time called timeboxes or iterations. DSDM calls them timeboxes, so I will adhere to that term here. Each Increment comprises a number of timeboxes, so that a theme develops incrementally over a number of timeboxes until it is in a cohesive state, when it can be delivered to Production.

Within each timebox, a sub-set of requirements (stories) is analysed in detail, the solution is designed, developed and tested, and preferably deployed. DSDM differs from the others in that it allows for the probability that work will take longer than estimated but allows for contingency in the form of additional, lower-priority user stories (Could Have’s).

What we are trying to establish at this early stage is “how big is this project, and when can we deliver it?”

To get the answer to this question, it is necessary to translate the story points into a measure of duration. This brings to the fore the slippery subject of estimating. To estimate the effort involved in delivering all of the stories listed (we had over 50 of them) would have taken virtually an entire day. We therefore adopted the idea of estimating only the stories in Theme 1. This would give us a reasonably accurate estimate (with a 70% confidence) of a delivery date for that Theme or Increment. I then took the total story point count for Theme 1, and divided it into the total effort estimated to give a ratio, that I then applied to the total story point count for the stories in the other Increments.

I then played around with some figures in Excel (as managers are wont to do), to try to work out the best duration for each timebox. Generally it is better to have short timeboxes than long ones, and for completely the wrong reasons (don’t even go there), I settled on a standard duration of ten working days.

Knowing how long each timebox would last, how many people were assigned to the project (three, plus a part-time tech lead), and the estimated effort required, I could easily calculate that we would need 11 timeboxes to deliver the entire project.

Right, that’s the high-level planning done. Now for the detail.

Agile Methods

Agile, as a development concept, has been around for more than 10 years now, and there are a number of different frameworks for being Agile. Basically, they differ only in the level of formality they prescribe. A decent comparison of the more popular methods is provided here

Our company has decided to standardise on DSDM Atern as the framework of choice. As you will read throughout this series of posts, I have deviated from the DSDM ‘gospel’, or introduced practices from other methods if I think they will be of value.

My chief criticism of DSDM Atern is that, like PRINCE2, it is heavy with deliverable products or artefacts. Atern prescribes the production of an awful lot of documents, which we are either scaling down considerably, or doing away with altogether. I hope to be able to describe what we are producing at each stage of the project life cycle as we go through it.

Agile - the start

I was surprisingly calm about the prospects of having to start managing projects at a new company and learn a completely new methodology as well. I had done it before, but all my previous employers used big, heavyweight frameworks high on process and bureaucracy. You don't have to think too much; you just follow the process. Like a robot. Agile is different. This company is different.

This is the first in a series of posts, in which I will describe how we adopted Agile in this company, and in what aspects we deviated from the ‘textbook’ approach and why. In this first post, I will run through the initial estimating workshops.

Agile textbooks suggest that the process begins with the initial idea for the project – the users should not know too much about the requirements too soon. In this case, a fair amount of thought had already gone into what the requirements were. The product owners were given a template into which they wrote a series of bullet-point requirements, essentially user-stories. The template was broken down by stakeholder, so that we could identify Customers requirements separately from Finance or Underwriting requirements, for example.

For companies adopting an Agile approach for the first time, it is essential that you get someone who understands the approach and how to adapt it. You will need someone to help guide you along the way and suggest how to do things to achieve the best results. In our case, we have nominated Geoff, a business analyst who spent most of December learning about Agile himself as our ‘champion’. He has also been able to get some consultancy time from Andy, who works for an external company who specialises in doing this sort of thing. Together they guided us through the initial couple of workshops.

It is vitally important that as many relevant people as possible attend these workshops to maximise universal understanding of the requirements and the drivers for the project. Because the project has not yet been formally approved, we were limited by the absence of a technical team – the developers who would undertake the work. They were, however, represented by the technical architect who knew more about the system and its functionality than any other individual. We also had no DBA or hardware specialist present. Hopefully their absence will not be significant at this stage.

Geoff had transcribed the initial high-level bullet-point requirements that the product owners wrote up, onto a pile of 4” X 5” cards known as story cards. These were then ranked into High, Medium and Low according to the perceived priority. We did this purely as a way of getting into the mindset of ‘chunking’ things up, a top-down approach, and relative prioritisation.

Story Points

For each (H,M,L) pile of cards, we then estimated their size and complexity in story points. There are a few possible scales to use for this but we settled on the most common one – 0,1,2,3,5,8,13,20. It is important that all aspects of the story are recognised, especially the degree of uncertainty. If the requirement is unclear (and it frequently will be at this stage), factor in the need for additional research, analysis, usability studies, etc, as well as the usual development and testing effort.

The thing to remember about story points is that they are relative only to other stories within the project. They are not comparable across projects.

Benefit

Once the story points had been allocated, we went through the cards again to assess the relative benefit of each feature. This is where the use of cards proved invaluable. The product owner and his team simply sorted the cards in descending order of which would provide the most benefit. We then annotated the cards with BB:1 for the card that provided the greatest benefit, then BB:2 and so on.

MoSCoW

Given the size and relative benefit of each story, the product owner then felt comfortable assigning priorities to them according to the MoSCoW scale of Must have, Should have, Could have or Won’t have.

This already looked like a fairly sizeable project, and getting to this point took up two half-day sessions, but it was well worth it.

My next post will describe the next stage of the process – determining duration.

Small company benefits

Even after just over a month here, the differences between working for a small company and a big one are profound. There is no security in reception for example; in fact there is no reception desk. I have not had to wear a ‘visitor’ badge for the first week until having my photo taken and a proper keycard made up. Instead I got keys to the front door and the alarm code on day 1.

I do not get bombarded with emails about how department X has developed a new process for handling work requests. Getting some software added to my PC does not involve a paragraph of justification, two layers of authorisation and three weeks lead time. Instead I asked the ‘IT Services’ guy – one of only two – to install Firefox. Two hours later, job done!

Resignation

In November '07, I was in a difficult position :

• My authority as a project manager had been usurped by a contract programme manager who was effectively doing my job as well as his own.
• I had little or no control over the (remote) suppliers I relied on, and was therefore ineffective.
• I had no further work scheduled
• A(nother) restructure had split the responsibilities of line management and project management in such a way that project managers like me had no control over the people who were assigned to their project. This, in my view, contravenes the number one rule of management - it's all about the people!
  

My position was untenable and I did the only thing I could. I resigned.

Of course, I got another job first. I had kept in touch with R, who had worked on Condor with me. He had moved to another company and by all accounts was loving it. So, when I felt I needed a change, I contacted him again and asked if his company had a vacancy. They did!

Before I go into details of my new job, though, I would like to comment on leaving the old one.

My terms of employment specified that either side needed to give 12 weeks notice. At the time I signed it in November '05, I wasn't planning to leave any time soon, and it was not something I thought I could argue about at the time. So I signed.

Now, two years later, I couldn't wait to leave, and had no inclination to wait around for 3 months doing nothing before I could start my new job. But having done a little research at my favourite resource on the subject of management, I went and spoke to my bosses boss, Gavin. It was he who had initially interviewed me, and if anybody had the final say on my leaving it would be him. Once I got confirmation from my new boss that I had got the job, I made an appointment to see Gavin one-to-one.
"I'm resigning!" I said as an opener. Beating around the bush is not his style, nor mine. He paused for a second, expressionless, then asked:
"What are the drivers?"
I explained that I had no control over what I was doing, that someone else was doing my job and that I could only get the opportunities I wanted elsewhere. He challenged me on that, but I wasn't there for an argument. I refused to say where I was going, and said I was here to "negotiate my exit date".

I argued that:

1. My project was due to go live within a week
2. I had no other work allocated to me, so would not have to hand anything over
   

And then I asked to leave in three weeks.

To my amazement, he agreed. With some proviso's. All he insisted on was that the project was implemented successfully as scheduled, and that warranty support was in place and working. Which was achieved.

I didn't quite manage to follow Mark's advice to "tell no-one", but I did make appointments with some people I wanted to stay in touch with and told them face-to-face. And I still have them as valuable contacts.

So, if you are in the same position as me, here's my advice -

1. Listen to the M-T series of podcasts on the subject
2. Find another job
3. Once you get it, resign face-to-face with your boss and negotiate the date you leave
4. Ensure that you tie up all loose ends - don't burn bridges
5. Be professional.
   

Good Luck.

In my next post, more about my new job.

Lessons learned

I learned a couple of valuable lessons from project Condor and my time at my last company:

It's not enough to sit back and do just enough to get by. You need to exercise your authority, take charge of the situation and generate confidence in other people's minds (your team's, your peer's and your bosses') that you are fully in control.
I need to have a team around me to be fully effective. My last project involved a third-party supplier up North, a business team in the West Country, and an Infrastructure team in London and Edinburgh (more about this another time, perhaps). I never felt fully in control of the project in that there was nothing I could do when things went wrong.

From now, though, things will be different. Very different!

Resigned

It has been a long time since my last post. I have little in the way of excuses, but here goes anyway -

After my last post, my responsibilities on project Condor, as I called it, were halved when another PM was assigned to help. I didn't take that very well. On top of the fact that I was going through some personal issues at the time, it made me feel very low indeed. The other PM took on more and more of the management responsibilities, and I let him. My motivation was at an all-time low. The project went live in September and I was not invited to the launch party.

Back in late June, though, I was asked to pick up another project because the incumbent had resigned. Initially, I was sceptical. They're giving me some unimportant little project that no-one else wants to get me something to do, I thought. But I was wrong. It was a large project, and a fairly important one. But if anyone else had refused it, they had more sense than me. I took it on, and steered it (sort of) into Production. Once again, though, it was believed I needed 'help' so a dedicated programme manager was assigned to 'help'. Of course, with nothing else to do, he took over and I had little to do.

So I waited until the project was nearly live, and then I resigned. That was in November.

In my next post, I will talk about resignations, in the follow-up I will talk about my new job, which is soooo much better!

Clockwork Condor

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.

Brainstorming and problem solving

It has long been thought that, in order to generate ideas or solve problems - indeed any activity requiring a lot of thought - that it is better to do so in a group. 'Two heads are better than one', right?

Well, yes and no.

Here is an interesting article which says that it is sometimes better to put a problem to a number of people individually first, then ask them to get together to discuss their ideas.

The researchers speculate that when a group of people receives information, the inclination is to discuss it. The more times one option is said aloud, the harder it is for individuals to recall other options.

I have an upcoming design workshop planned - the perfect opportunity to try out the theory.

Directing people

A friend once told me that to succeed as a manager, you need to command. It's not the only criterion, but being able to command both attention and respect go a long way towards getting what you want. That and providing direction. Command and Direct. That, in a nutshell, is what managers do.

Today was a case in point. The boss (who is actually pretty good at this stuff) was away today, so I was able to do some commanding and directing of my own.
During a workshop intended to clarify some concerns with our requirements specification, it became clear that we were still unable to get answers to all our questions. On a project with deadlines as tight as this one, further delays are just not good enough. So, I directed. I commanded. I said, "minute the agreements, assumptions and actions we have agreed here today, then put all the unknowns in the Functional Specification under the heading of 'Out of Scope'. Then focus all your attention on all the stuff you do know about".

Unfortunately, this has the side effect of potentially delaying things even further, because with the requirements baselined, any changes will now need to be assessed via the change control process. This might be considered an overhead, but it's the only way of ensuring that the high priority requirements are delivered on time.

Attention must be focused on what's really important.

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.

Secretarial pool for managers

I moved desks yesterday.

Actually, I was evicted from my old desk because someone else was drafted in to help out with a project in crisis. So I was asked to move to another floor entirely.

As most of you will probably know, desk moves have their pros and cons. I my case, they were mostly cons. My old desk was on the same floor as the key members of my team. My tech lead was right beside me and the lead analyst directly opposite.

Remember those old secretarial pools they used to have in the days before desktop computers? Well I am now in the secretarial pool for managers.

You see, the 9th floor is made up almost entirely of managers. There are one or two senior analysts around, but mostly it's just project and programme managers. Quite why anyone would decide to seat so many managers away from their teams is completely beyond me. Anyway, hopefully this is just temporary.

The usual up side of a desk move involves a process I call upgrading. The idea is to have the best workstation in the building - and it can take years.

Even in today’s corporate world of uniformity, there are often small differences between workstations. When a new batch of office chairs comes in because loads of new people are starting, they are very quickly swapped for old ones by the sharpest of incumbents. When one of those incumbents is asked to move desks because one of the newbies needs to sit where he is, he takes his new chair with him. See how it works? These people are upgrading. Accumulating office 'wealth'. When someone leaves the organisation, there is a swift reaction from the old hands. They immediately compare the 'wealth' of the leaver with their own, and very quickly they pounce on the optical mouse that the other guy left behind, or swap their own 1.6Ghz CPU for a 2Ghz one. That grimy keyboard with the sticky 'G' key (the result of a coffee spillage last year) is swapped for the newer, cleaner one. You get the picture.

So when I packed up my books, files and papers, loaded them onto my fancy new chair and wheeled it up to the 9th floor, I was disappointed to see a slower processor, dirtier keyboard and older mouse with no wheel!

The only up side I can see is that I have a better view out of the window. Of the building across the street.

And it's quieter. That's good.

The dreaded D word

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.

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!!

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.