Extreme Project Management for Architects
This paper lists and describes practices unique to XPM, organized by triggering mechanism. Traditional common-sense practices aren't included unless they're done differently using XPM.
The following practices are triggered when a team is ready to start a new project.
XPM is not appropriate for every project. Choosing to use XPM and following its practices is voluntary. All team members must agree. How do you decide? Survey the team using this list as a guide. Discuss the practices, evaluate the comments, then decide.
Hold a project kickoff meeting to:
A project plan is a list of tasks required to complete each phase of a project. Create it using spreadsheet software or make a set of task cards (which will be discussed later), one for each task. List every task you can think of to complete each project phase. At this level, tasks can be coarse-grained and general, not detailed. They'll be broken down later. A task for schematics might say "draw schematic floor plans". Another for design development might say "update floor plans to DD level".
Besides tasks to create deliverables, don't forget tasks for meetings and reviews.
Estimate and record the time required to complete each task. Total the time required to complete each phase and compare it with your project budget.
Estimate the time in ideal hours, that is, the amount of time it would take if you could work on that task without interruption. After using XPM for one or two iterations, you can calculate the ratio of actual to ideal hours and ideal hours to billable dollars for more accurate time and cost estimates.
The following practices are triggered when the team is ready to start a new project phase: schematics, design development, contract documents, etc.
Create a release plan for each project phase. A release plan is a stack of task cards that represents all the work required to complete the next phase of work. It's usually a subset of the project plan, perhaps with more detail. For more information, see release planning tips.
Store the task cards in an index card box with tabs or post them on an iteration board: a board with task cards arranged in columns by iteration. Later during the project, add, move, remove, and redistribute the task cards as required.
The placeholder/progress set lets you see current project status at a glance. Create a separate set for each set of deliverables. A placeholder set is a progress set that uses placeholders for unfinished drawings, sheets, or other items. As work is completed, replace the placeholders with real drawings. The placeholder/progress set shows what's known as well as what's not known, work done vs. work remaining.
I initially called this a working cartoon set but now think the new name is more appropriate. A placeholder set has far less detail than a cartoon set. It shows only what is included, not necessarily where. Placeholders can be represented by notes or scraps of paper, not cartoons or sketches. For more information, see working cartoon set, a paper I intend to revise and whose name I'll change later.
The next set of practices are triggered at the beginning of each iteration. An iteration is typically one week long. For reporting purposes, iteration length must be constant, but need not begin on Mondays.
Hold weekly planning meetings at the same time and day each week, say Tuesdays at 10 AM. Everyone involved in the project attends. During each weekly planning meeting:
Right from the start, at each iteration, deliver visible value. Merge new work into the placeholder/progress set: new or updated drawings, details, specifications, etc. Review, celebrate, and show improvement each week.
Hold short retrospectives each week to discuss project-related issues, to learn, and to make adjustments accordingly.
Holding retrospectives each week lets us deal with issues quickly, solve them incrementally, or postpone them for later.
How are problems resolved? Look to the practices first. Do they need to be modified? Are they not being followed? Most problems occur because recommended practices aren't being followed.
Create an iteration plan prior to or during the weekly planning meeting. From the release plan, select the highest priority tasks to be completed this iteration. The number of tasks selected are based on the team's velocity.
Let me supplement this discussion of iteration plans with a few sub-practices related to velocity and tasks.
Track team availability and velocity to determine the number of tasks to select for the coming iteration.
If the same team members work on a project the same number of hours each week, you can expect a fairly constant amount of work to be completed each iteration. In XPM, we measure work on tasks in points. A point is equal to an ideal hour of work on a task. We call the number of points completed each iteration the team's velocity and we choose tasks for the coming iteration by choosing the same number of points as last iteration. If our velocity was 100 points last week, we choose 100 points this week.
If team members can't work the same number of hours each week, track availability and adjust velocity accordingly. If you completed 100 points last week with a team having 150 available hours, but this week the team has only 75 available hours, select only 50 points.
In XPM, no work is done without a task card. Anyone can create one, at any time. They're usually created before or during weekly planning meetings.
Write task cards on 3 x 5 index cards quickly but legibly:
Iterative tasks are those that occur each day, week, or other recurring time period: attending weekly meetings, updating progress sets, uploading drawings, maintaining filing systems. They require about the same amount of time and effort each time period and their scope of work doesn't change over time. Thus, they can be factored out of task selection and velocity calculations.
Most iterative tasks require consistency and continuity, and are best handled by a single person. Have one person sign up for each iterative task for the current phase or for the project's duration.
In XPM, only tasks selected for the current iteration are worked on. After the cards for the iteration have been selected, post them on the task board so team members can begin signing up and completing tasks. Group cards by category to make selections easier.
After collecting metrics from the prior iteration, create a set of management reports. Post or distribute them for all to review. Limit reports to what's really needed to help control the project. Two reports are usually adequate:
XPM reports provide tracking information that can be used to accurately predict future production, manpower requirements, schedules, and profitability.
Daily practices are triggered by each new work day. Try to do them first thing in the morning, after the team has had a chance to get coffee, review emails, and prepare for the meeting. Meetings at 9:30 AM seem to work well.
Meet to discuss project status at the same time each day. All team members attend. Stand up to keep the meetings short, about 15 minutes.
One by one, each team member:
Show what was done to provide a visual image for the team. Tell what will be done as a commitment to other team members and let them know what's in progress. Identify obstacles so the whole team can offer suggestions, management can remove them, or they can be discussed in weekly retrospectives.
During the meeting, team members are welcome to offer comments, make suggestions, or ask questions. Briefly. Set up ad-hoc follow-up meetings for topics that require more intense discussion.
In addition to daily stand-ups, any team member can call for an ad-hoc stand-up at any time to discuss an important team issue.
Start stand-ups with team announcements. Report on new task cards, recent meetings, receipt of documents, and other issues or events of significance. Set up ad-hoc meetings for detailed discussions later.
Keep announcements short. Maintain a balance between keeping the team informed and taking too much time in the meeting.
Task-related practices are triggered when a team member is ready to select a new task. Team members choose tasks from the task board. The choice is based on their desire and ability to complete the task as well as their inclination to learn something new, time constraints, and other project related circumstances. One or two people sign up for each task. After they complete the task, they select another.
In XPM, a project is controlled with task cards. They define what will be done and when. They define the level of quality expected. If there is no card for a task, don't do it.
Task cards include a title, perhaps some notes and a time estimate. They don't describe the task in detail. Even though each task card is discussed in the weekly planning meeting, the scope and expectations are usually unclear. To clarify, talk to the card author before and while completing the task.
How do you know a task is done? How do you know it's done right? By testing. If you write, or at least consider, tests before completing a task, you'll spend more time focusing on the actual task and less on sidetracking issues. Tasks get done faster. Do only what's required to pass the tests for the current task, no more and no less. It's usually easier if you pair to write the tests. For more on this, see testing and testlists. If you can't test, devise alternatives.
Many tasks tend to be repetitive with minor variations, especially in the contract documents phase. For example, drawing window and door details requires showing different but similar conditions. Creating prototypes for repetitive tasks saves time. Details based on prototypes require less time to make decisions, less time to draw, and less time to review. For more on this, see using prototypes.
After the task has been completed, the tests all pass, and the task has been reviewed and accepted by the "customer":
There are three parts to every meeting. Pre-meeting, post-meeting and the meeting itself. Pre-meeting practices involve getting ready for the meeting. Post-meeting practices are related to debriefing and following through on action items.
Meeting practices are, of course, triggered by meetings. Think of meetings here in the broadest sense: presentations, interviews, site visits, inspections, one-on-ones, team meetings, etc. Even a phone call could be considered a meeting.
Keep meetings short by focusing on one or two topics. Except for planning meetings and retrospectives (which everyone attends), most XPM meetings are face-to-face stand-ups, with attendance limited to those necessary.
Whether you are the meeting chair, an attendee, or just an observer, reflect upon and create a list of objectives. List, mentally or in writing, what you want or need to get out of the meeting. If you can't come up with a list of objectives, question whether or not you should attend the meeting.
Write task cards for things that need to be prepared before the meeting, things that take more than an hour or so, that you can't do yourself as part of the meeting. Discuss the cards during weekly planning meetings. Most meetings are scheduled long before the actual meeting and can be prepared for accordingly.
After (or during) the meeting, write task cards -- a separate task card for each action item. Let nothing be forgotten. If a task has a deadline that falls within the current iteration, announce it during the next stand-up meeting. Otherwise, store the card with the release plan or in the "to be done" task card pile, ready to be discussed at a future planning meeting.
If decisions have been made during the meeting that might effect other team members, make an announcement, briefly, at the next stand-up meeting.
Unplanned tasks are those, usually initiated at a meeting, that were not anticipated in the weekly planning meeting yet must be done during the current iteration. Identify cards with unplanned tasks by a special symbol so they can be easily identified and tracked in weekly management reports. The time spent on unplanned tasks is included in velocity calculations, but tracked separately. For more on this topic, see planning vs. putting out fires.
Milestone practices are applied at the end of a release, a project phase, or project.
The end of each major milestone:
XPM guidelines are practices that don't have well defined triggers. They're often diffused rather than triggered by recurring events. Some are repeated continually, others only occasionally.
Team members are often more comfortable discussing difficult issues in one-on-ones rather than group retrospectives. One-on-ones provide an opportunity to discuss issues on a more personal level. When and how often one-on-ones are held depends on the project and the team. I'd recommend they be held when team morale or energy seems to be declining.
In XPM, everyone works together, as a team, in the same space. Information flow is maximized by people working next to each other. Questions are answered fast; decisions are made fast. No waiting, no delays.
Pairing is one of the most effective ways to share knowledge and learn from each other. It helps speed production as well. Two people working together rarely agree to do unnecessary work.
Pairing means two people work together to complete a task. Where pairing seems inappropriate, practice partial-pairing. Pair at the beginning of a task to discuss what will be done, pair at the end to review what has been done.
In XPM, tasks are assigned to the team, not to individuals. Team members choose tasks based on their knowledge, experience, desire, inclination, time schedule, and other considerations. Besides providing more options for team members, distributed responsibility eliminates bottlenecks.
Taking this even further: Break roles down into tasks and assign those to the team as well. Finer grained tasks provide more options for distribution. For example, break the project manager's role into sets of iterative tasks: coordination reviews, attending client meetings, reviewing incoming correspondence, etc.
Iterative tasks such as these are handled differently than ordinary tasks. They require continuity. Team members sign up for a specific duration.
In XPM, the team owns the drawings and specifications collectively. Any team member can work on any sheet or change any drawing, at any time.
That doesn't mean changes can be made randomly of course. Changes are made only if a task card requires such a change. And, after the change is made, the tests must still all pass, and the customer must approve. If pairing, each partner must approve.
Collective ownership may not always be appropriate. The team must balance its desire to share learning and prevent bottlenecks with the efficiencies of sole ownership.
However desirable, everyone involved on an architectural project can't realistically work together in the same room. In architecture, everyone means the entire project community: the architectural project team including managers, spec writers, designers; the client, contractor, consultants, review agency representatives, manufacturers, product suppliers, etc. We have to resort to meetings, phone calls, emails, faxes, instant messaging and other alternatives to replace face-to-face meetings.
Sometimes these alternatives aren't effective. When they're not, assign a proxy. A proxy is a team member who represents the missing person or entity; a person who acts as liaison, assuring that information is transmitted both ways, to the team and from the team.
When team members agree on and adhere to a set of standards, work gets done faster and is more consistent. However, our primary objective is a successful project, not a comprehensive set of office standards. Maintain office standards, but keep them to a minimum. Focus on the current project. For example, instead of detailed written notes, draw an annotated prototype. Rely on the team's daily face-to-face discussions to evolve the specifics.
Team members work hard and at a pace that can be sustained over time. They rarely work overtime.
When decisions become controversial, involving time-consuming discussion and arguments, save time and make reliable decisions by performing experiments. From Ron Jeffries: "Speculation or experimentation -- which is more likely to give the correct answer?"
For example, say you want to adopt a controversial new practice to solve a problem. Instead of spending an hour discussing the pros and cons, agree to put the practice into place for a week or two as an experiment, then evaluate the results.
Put deliverables into the hands of whoever needs them as soon as reasonably possible, so you can get feedback. Distribute deliverables often and consistently, so you can get feedback. People make better decisions when they can see what's involved.
Work faster by working with what you've got. That is, start now; don't wait until you gather all the information required to make a decision. Base decisions on what you know now. You'll learn more later.
To complete a task quickly, try something -- the simplest thing that could possibly work. Make it freely available for all to react to. Maximize the opportunity for others to comment. Collect responses and make improvements based on what you've learned. It's easier for people to know what they want or don't want after they see it.
Changes are inevitable, especially when working iteratively and incrementally. Show what you know, learn from feedback, and improve a little at a time. Expect to make mistakes; lots of small ones. Small mistakes foster faster learning.
Although counter-intuitive, an effective way to work fast is to generate alternatives. When given the opportunity, generate alternatives and choose the best. Create alternatives quickly. Then get feedback and make improvements. Ignore constraints. Experiment. Do it fast. Evaluate and choose. Merge ideas to generate new alternatives. Make choices and modifications based on feedback, experiments or consensus; not guesses.
All XPM practices are voluntary. Eliminate those that don't help achieve your goals. Add new ones that help. Modify practices that require it. However, make changes based on experiments, not speculation. Try the practices for a while before eliminating or adapting them.
Setting-up isn't really a practice; it's a one-time activity. But the right setting is important; it helps facilitate most of the other XPM practices.
XPM works best in an open environment where people, ideas, and artifacts can flow freely. Provide an environment where it's easy for everyone to work together in small and large groups. Provide plenty of communal space for team members to share and display drawings and other work products.
Practices as Habits for Teams looks at practices as habits, not rules, for teams.
Extreme Project Management provides additional material on XPM practices.
Assigning Tasks talks about how tasks are assigned.
Click here for a version of this page that's more suitable for printing. After printing, click the back-arrow of your browser to return to the original format with an index alongside.
I welcome your comments and suggestions. See contact us for more information.
Copyright 2005 - 2007, Dennis V. O'Neill