The Benefits of a Winding Path
In a previous post, I wrote about momentum problems with our team’s help system design project (a.k.a. HD). I am happy with the unexpected benefits and the unexpected learning opportunities that the project yielded, but the amount of time it took still seems inordinate. After posting, I got curious about ways to plan a project while leaving room for those types of fringe benefits.
Here are some of the benefits we got out of spending so much time with the project (and with each other):
- Team building skills
- Consensus building skills
- Client service skills
- Survey-writing skills
- Presentation skills
- Training skills
- Research skills
- Whatever other technical skills necessary to produce the deliverable (our deliverables were XHTML topic templates for each information type, plus methods to guide our team in converting tens of thousands of topics to a new format)
Stopping for Directions
It seems like it would be easier to plan ahead for gaining bonus skills and relationships by being honest about not having them in the first place.
Um, doesn’t that mean you won’t get to participate in the project?
It depends. Is the culture of your team that people are encouraged to take projects in order to grow skills? There’s more to it than cranking out documents to get deliveries out the door—it takes an investment of time to advance the team’s skills. Is it a critical deliverable for a critical client? Is there someone on the team who is already an expert who can take you under their wing? If there is an expert, but they don’t have mentoring skills, what then?
I can’t imagine my manager refusing to let someone participate in a project they were interested in without helping that person find another way to develop the interest. In addition, one criteria for getting promoted is to act as a leader and a mentor. There is incentive to grow these skills. There is opportunity to work on new things. I think these two things work together to make the team sustainable. I know this combination is one of the biggest factors in my having stayed on the team for four years.
Planning Ahead for Detours
After HD, I’ve established for myself that fringe benefits are usually worth the time they add to a project. This week I’ve been thinking of ways to draft a project plan at the outset that I can use to justify the skill development.
List the Expected Deliverables
This and the next item were inspired by GTD, which I read over six months into the HD project. List anything you will be expected to produce for the project, such as training, templates, presentations for each stakeholder group, status updates for the larger team. List them for your manager to make sure your expectations match hers.
This is a good time to candidly discuss with her if any of the deliverables make you nervous. “I’m not good on the phone,” or, “It usually takes Dave and I a while to come to agreement.” You can brainstorm with her how you will address the concern. Do you need to build extra discussion time into the project plan? Do you need to attend your company’s meeting training and agree on a meeting format for the project?
Add the concerns and the necessary time to the project plan. If you’ll have to research something in order make a decision, add time for that, too. If your manager balks at the extra resources, she can recommend another way to address the need.
You can always ask again in the midst of the project if it becomes apparent that you really do need the research or the discussion. I can think of so many meeting discussions that ran over the allotted agenda time when it would have been useful to be able to say, “Our project plan says we will have this decided by today. Do we need to add a week to the time line so that we can have this decided by next meeting?”
List the Criteria for Success
This is also GTD-inspired. We were almost finished after a long, rough ride on the HD project. We were ready to present to the team and start using the new format. Our manager asked us to present to her first. Then she proceeded to rip holes in our design. We spent another month getting the new templates up to snuff because they didn’t meet her criteria.
We should have clearly discussed criteria for each project deliverable ahead of time, and we did at that time. It was frustrating to be having a discussion we clearly should have had at the outset to make sure our criteria met the department needs.
I almost think you can’t be too detailed about doing this. Probably each deliverable should have criteria that you can refer to when you are deciding if the deliverable is good enough.
This Advice Fits in the Glove Compartment
Groan, I know. Sorry. I think what it boils down to is to be explicit at the beginning of a project about what the project parts are and where you will need to develop team knowledge in order to be successful. Then make that development part of the project. Add skill development as tasks and allocate time for it. You might not get everything you ask for, but at the very least you’ll be clear about which team skills you’re developing in this project and which ones you are postponing for another time.
