Friday, August 8, 2008
If you ask people to do two, three, or more things, they won't do any of them. Especially if they are volunteers, or are only part time on your project. But if you ask them to do ONE thing, and ask them when they can complete it, they'll almost always do it.
This is why daily stand up meetings are successful: what are you working on, what did you do yesterday, did you finish what you hoped to, and did you run into any road blocks that I can clear away.
This also has an impact on the size of the tasks you create in a project plan. In my opinion, they should be no smaller than a day's work, usually about a week's work, and no more than two week's work.
I implied earlier that having shared resources is often difficult. It provides them an excuse for not completing their tasks. If you have a critical project, make sure your key resources are dedicated to your project, and their other duties are handled by someone else.
Tuesday, September 25, 2007
A little background on the two projects I managed, and the companies involved: In 2004, Gambro BCT (now CaridianBCT) bought a small sterile solutions manufacturer in Northern Ireland (by the way, for all you Americans, that's in the UK! It's kind of like New Mexico and Mexico!). CaridianBCT is launching a new product where integrating small sterile solutions will be critical. Very few manufacturers are in the small solutions bags. Baxter makes 2 litre bags by the billions, but nobody makes 250 ml bags. That's what Ivex Pharmaceuticals in Northern Ireland does. CaridianBCT employs a couple thousand people. Ivex has around 120 people, and most managers wear many hats, and do a lot of the paper work themselves. Other than that, the companies' cultures are remarkably similar, and the people at Ivex are warm, friendly, humorous, and great to work with.
Here are some of the lessons I learned from these two projects:
Plan Regular Face-to-Face time
Conference calls just don't do it. You have to plan regular time when you fly there, or they fly here, or both. It's the only way you'll get agreement, and wrestle things to the ground.
Know Your Stakeholders!
We thought that Quality was our key stakeholder on one project, and it was, but so was Finance. Finance was involved, but when we went live, they held things up as they didn't have test plans to assure them that all the data had transferred correctly. We should have realized that, and planned ahead. Instead, finance went off in a corner by themselves and did the testing over several days rather than several hours, almost killing our project.
Even in a Predictable Project, Plan For the Unexpected
We were implementing an accounting and manufacturing system. We had done this many times before, so we knew everything to do right? wrong. The data was a total mess, and had to be totally rekeyed. Plus, many of their business rules didn't agree with ours, so we had to change how they did business in some instances. In most instances, we let them run things the way they wanted, but some accounting issues had to be standardized - that was the point of the project.
No one at Ivex was accountable for the success of the project. If we failed, no one would be bothered, and if we were successful, no one got rewarded. So they wanted it to fail. Well, not openly, but they didn't really care, and hoped that they could go on doing things the way they always had. The success of the project should have been on the performance evaluation of their stakeholders.
Know the Culture
The culture in Northern Ireland is remarkably similar to American culture, but there are still many differences in how you deal with problems, concerns, issues and conflict. Learn from others before you how it works in each culture. Each country has its own culture, and there are even regional differences in large countries like the US.
Monday, September 17, 2007
So what is a high performance team, and how do you recognize one? That's a tough question - almost as tough as a definition of Agile development (there's no official definition of that either!). But here's my take on it:
- All team members share the same project vision - they are 'jazzed' about what they do, and what they can contribute
- Every team member is a "leader", and all share responsibility for everything on the project.
- Excellent communication exists within the team
- High team spirit, high morale exist.
- The team meets goals, objectives and deadlines
Death of "the Job"
'Jobs' didn't exist before the industrial revolution. People were put in factories, and told to do one thing (their 'job'). Later, unions took this idea of 'the job', and ran with it. Jobs were created, and people were pigeon-holed into doing one job. Even today, some union jobs are for lifting things under 15 pounds (7 kg), and others are for lifting things over 15 pounds. I credit unions with creating one of the worst phrases known to man: "that's not my job". Such attitudes do not and cannot exist on high performance teams.
Does that mean that high performance teams are some sort of commune? Of course not- every team member still fulfills clearly defined roles, such as Project Manager, Developer, Training Coordinator, Logistics, and so on. As a project manager, when I assemble a new team for a project, the first thing I tell them is that though I'm the project manager, I expect them to be my eyes and ears, and help me identify tasks that need to be accomplished, and risks that could affect the project. I go on to say that I expect everyone to help everyone else who is on the critical path. For example, if we can't train everyone fast enough to roll out the software on time, then everyone on the team becomes a trainer, helping the Training Coordinator.
Another key element of fostering high performance teams is having daily stand-up meetings, where tasks are identified, status is reported , and any new risks are identified and discussed. These stand-up meetings are key to fostering excellent communication within the team, prioritizing work, and keeping morale high. Everyone knows what their tasks are for the day, and are much more likely to get them accomplished. Everyone becomes accountable to the team.
Everyone on the team needs to be recognized and valued for the skills and expertise they bring to the table, and everyone needs to feel free to express their ideas and share opinions. (One high performance team I participated on even went to a one-day Myers-Briggs class to help us better recognize and value the different perspectives we each had.) Over time, the team evaluates its own performance and becomes self-directing. It transforms into a hard-working organization that is having a lot of fun.
Thursday, September 13, 2007
From time to time, I will be posting my philosphy, lessons learned, and war stories about my experiences as an IT Project Manager working for a Medical Device Manufacturer. My point isn't to rant, but rather to share insights that will be of value to others that follow. The range of topics I'll cover will include:
- IT Project Management
- FDA validation
- Agile Development (in the FDA regulated environment - yes, it can work!)
- Working effectively with co-workers
- Creating High Performance Teams
I work at Gambro BCT, and you can read my profile at the icon/link below.