Much has been written about requirements, and surely we have experienced enough to have learned how to do things in ways that support successful project outcomes. Yet, many projects encounter requirements-related problems, most of which could have been avoided. Ample guidance is available to enable successful project management and to perform effective requirements practices [1, 2, 3, 4, 5] that are easy to apply.

Table 1 provides a set of 12 requirements basics for project success with supporting information, suggestions, and recommendations provided in this article. I encourage you to consider them thoughtfully in the context of your project and to determine if some changes in its approach may be worth considering. (Of course, if you digest this article and then decide to make no changes, no improvement opportunities will result. Failure to work proactively to continuously improve is a root cause of a lack of improvement in project success rates [6].) You may relate to the Requirements Secrets provided in Table 2. The sad truth is that these are not really secrets; they are fairly well-known facts that are well documented in the requirements literature (books and articles written by academicians and practitioners concerning requirements). So, the bottom line is not that we do not know what to do, it is that we do not do it – a sad commentary on our willingness and commitment to discipline our efforts on projects.

Table 1: Twelve Requirements Basics for Project Success

Table 2: Requirements Secrets

Related to the importance of requirements basics is the need to be agile. How does one balance increased investment in the requirements process with the need to be agile? In my judgment, it is the project’s approach that makes all the difference. By using an evolutionary or incremental approach, and by delivering versions, releases, and new products, we can be agile. It is not required that we learn a whole new way of doing things.

Twelve Requirements Basics for Project Success

Concerning potential improvements in your project’s approach, we need to remind ourselves that each of us is a change agent on our jobs and on projects. Select an improvement opportunity from the following where you have influence and show others that you can be successful.

Basic 1: Provide training for all project participants concerning the requirements processes to be used on the project. Also, there needs to be a technical leader who is highly skilled in requirements engineering. The training and experience required for three levels of a requirements analyst (RA) are provided in Table 3. See [5] for more information and insight, including an extensive set of references to excellent requirements books and articles by many good writers. Industry systems engineering and requirements trainer Robert Halligan believes that the number one problem in requirements engineering is that project managers (PMs) fail to require experienced RAs, and that RAs are not sufficiently trained and/or experienced to perform their roles effectively¹. PMs can use this skills matrix to recruit and train RAs; RAs can use it to pursue an ongoing professional development program to acquire needed expertise.

Table 3: RAs Skills Matrix

It is important to distinguish between a process and the skills of project professionals. A process may be defined as a set of activities that results in the accomplishment of a task or the achievement of an outcome. Every project uses a requirements process whether it is defined and documented (written down) or not. Some of the advantages of involving a project’s key leads in defining and documenting the requirements process for a project include the following:

• Because they helped create it, the people involved in defining and documenting the process acquire a better understanding of it and become more committed to its successful use.
• The leads for other areas within the project become more involved in the requirements activities and bring their expertise and experience to refine the requirements process.
• Once the process is documented, the opportunity exits to improve it based on actual project events.
• The process is likely to be more complete and useable.
• The process is more likely to be integrated into other activities and plans on the project. In other words, by using a collaborative approach, project communication is enhanced.
• Technical performers on projects become more inclined and willing to use an agreed-upon and understood requirements approach.

When addressing the skills of a requirements analyst in Table 3, think of these skills supporting the project’s requirements process. The process goals are created to perform requirements work effectively and successfully; the skills applied by the requirements analyst facilitate the performance of the requirements work. For example, by ensuring that each requirement meets the criteria for a good requirement, the RA enables the project to avoid a lot of rework, thus making the requirements process much more effective. Another example is that by utilizing the joint team mechanism (a way to do something), responsibility for the requirements is fixed – all requirements go through a funnel so that accountability for them can be maintained. The joint team mechanism needs to include a few representatives (between two and 12 or more, depending on the size of the project) of both the customer/user and the developer who are empowered to make decisions and take responsibility and accountability for the requirements throughout the project’s life cycle.

Basic 2: Proactively partner with your customer. In our work, project practitioners like to use the word partner . It suggests that we are collaboratively working toward joint objectives. I am talking aboutin which an independent outside facilitator is engaged to orchestrate an approach in which a set of carefully selected stakeholders gain commitment to success through a series of planned partnering workshops². The advantage of this approach is the evolution of a team that is committed to project success – it will not allow the project to become derailed in spite of the inevitable problems and interpersonal issues encountered during the days, weeks, months, and sometimes years of hard (and often conflicted and frustrating) work. Wiegers provides related ideas concerning having a product champion as a specific partnering technique in [9].

Basic 3: Understand the resources required to perform requirements processes effectively and invest in the project’s requirements process. The industry average for project investment in its requirements process is 3 percent of project costs; data from NASA shows that when 8-14 percent of project costs are invested in the system life-cycle requirements process, there is a much higher probability of achieving lower costs and improved schedule [10]. The requirements process used by the project or organization should be 1) developed by the project’s stakeholders and staff; 2) documented; and 3) continuously improved based on experience on each project. Measure the requirements change activity (requirements volatility), including both new requirements and changes to requirements, to provide insight into project performance. Also, plan for change; this means estimating the amount of change and when it might occur.

Basic 4: Write a project vision and scope document. The benefit of this recommendation is to document the vision of the stakeholders concerning the goals of the project, and to achieve significant consensus on the project’s scope (what is included in the project and what is excluded – for example, product will not support users in Ireland until Vers. 3 ). A template for this document is developed by Karl Wiegers [9] and is represented in [15]. In our work, we need to be aware of the need to involve all stakeholders and to gain buy-in (commitment to the success of the project). Allowing various stakeholder groups to review the vision and scope document, comment on it, and then revise it to address their stakeholder comments is one technique that can help gain buy-in. One project best practice is to engage stakeholders throughout the project – projects that do so are more successful than those that do not because communication is improved and expectations are more realistic [7]. Also, this provides more opportunities to build interpersonal relationships and even allows customers and users to help solve the problems that arise.

Basic 5: Use proven requirements elicitation techniques such as requirements workshops and prototypes and other forms of visual presentations to evolve the real requirements³ and to gain stakeholder buy-in [11]. Among more than 40 requirements-gathering techniques, these two seem to be the most effective. In the case of the former, various stakeholder groups will learn more about the perspective of the other stakeholder groups and will have a better understanding of the overall needs to be addressed. Another use of requirements workshops is to review issues and make decisions that best serve all stakeholders. The latter technique is a cost-effective way to gain a better understanding of the customer’s and users’ real needs – prototypes may be designed, developed, implemented, and updated for a fraction of the cost of a delivered capability. Getting feedback on a visual representation is faster and easier than getting it from text. The important thing is to evolve the real requirements before starting other technical work. Experience has shown that using the stated requirements (the requirements provided by the customer and users at the beginning of a development effort) results in an estimated 45 percent rework [12].

Basic 6: Utilize an evolutionary or incremental project approach to development, deployment, and implementation of the needed capabilities. This is both an opportunity and a challenge – whenever one employs a new technique on a real project, additional risk is assumed. My suggestion is to ensure that there are people on the project staff who have previously utilized a new practice, technique, method, tool, or mechanism. In this way, your project can benefit from lessons learned previously (provided, of course, that you pay attention to and are disciplined to incorporate them). An evolutionary or incremental approach allows the project to build hunks of delivered code at a time, and then uses them to learn how and where to proceed. Use versions, deliveries, releases, and new products to accommodate the inevitable requirements changes.

Basic 7: Use an effective mechanism to control requirements changes and new requirements. Controlling changes may mean generating new releases. Most projects utilize Change Control Boards (CCBs), but they usually address detailed project activities such as changes in the code. Use of a higher-level CCB (for example, the joint team I recommend to be responsible for the requirements) to maintain control of the requirements is a good example of applying added discipline on a project. It is logical (though most often not done) that requirements should be prioritized, and that the highest priority and most difficult requirements be addressed first. One reason to do this is that some requirements areat the beginning of a development effort; it requires some development work and related research effort to discover them. It is critical to understand that changes to requirements and new requirements can cause a project to go out of control, thus creating the need for a mechanism to control them. I recommend limiting changes to a maximum of .5 percent per month (6 percent per year) in the capability currently being developed in order to help keep the project under control [13]⁴.

Basic 8: Use an effective automated requirements tool to maintain information about the requirements. Although many projects do not follow this practice, in my judgment, an automated requirements tool is required for any project except tiny ones. This is because it is necessary to have a lot of information concerning each requirement – its attributes . For example, we need to know the following:

• The source of the requirement (who nominated it).
• A unique identifying number for it.
• Its priority (on a scale of one to three).
• Its relative cost to implement (low, medium, high).
• Its relative difficulty to implement (low, medium, high).
• Each requirement meets the criteria of a good requirement (the criteria shown in Table 4 should be met for each requirement. If they are not, it is likely that the requirement statement is not really correct).
• The rationale for the requirement (why is the requirement needed?) [15]⁵.
• Change history (how has the statement of the requirement changed over the system life?).
• Traceability⁶(of each requirement to its source, as well as the design, code, test, documentation, and training materials).
• Status (draft, final, approved, pending approval, disapproved).
• Assigned to (component of the system).

Table 4: The Criteria of a Good Requirement

Two related needs should be considered. The first is that the requirements are used by different people (including customers, users, and project team members) with different viewpoints [16]. We need to be able to organize the requirements to provide different perspectives, for example, for customers, users, or testers. The order and the actual requirements selected for these activities are dependent on the viewpoint. The second need is that at any given time, one may need to see all requirements or only those changed ones; an automated requirements tool provides the capability to obtain various reports that are required to perform good requirements work.

Basic 9: Avoid requirements errors. A requirements error is a defect that is discovered in delivered code that is a result of a requirement statement. Data from NASA provided by requirements consultant and trainer Ivy Hooks show that 80 percent of the requirements errors that remain in delivered software are a result of incorrect facts (49 percent) and omitted requirements (31 percent) [10]. This is truly amazing when you think about it – clearly a key opportunity to improve requirements work. Making a concerted effort (investing more in the requirements process) to avoid these two types of requirements errors can save money and time and also improve the quality of delivered capabilities.

Some of the things that can be done to address incorrect facts include the following:

• Provide stakeholder reviews of requirements work products.
• Require that an authoritative source document be specified.
• Require verification of each requirement as part of the planning for testing.

Some of the things that can be done to address omitted requirements include the following:

• Elicit requirements from a variety of stakeholders.
• Conduct requirements workshops and review the requirements collaboratively.
• Conduct formal requirements reviews.
• Ensure that all high-level requirements are addressed and met in the requirements work products.

Basic 10: Utilize inspections of requirements-related documents. Inspections are not difficult to perform, and their use is cost-effective; a concise explanation of how to perform both peer reviews and inspections and how to install a peer review process on a project can be found in [8].

Basic 11: Enlist the support and assistance of all members of the project staff in performing requirements work. It is not just the requirements manager and/or the RA who need to be involved in requirements-related work on a project. Most members of the project staff can help; however, they need to be made aware of how they can help and that the PM’s expectation and request is that they do help. A technique I have used successfully to accomplish this is an early project requirements briefing that is made to the entire project staff. Participants in the briefing can be invited to suggest how they can help with the requirements work with the objective of optimizing the efforts of all project members. A related need is to develop a strong sense of teamwork throughout the project. In my experience, an empowered and committed team can accomplish most anything it sets out to do.

Basic 12: Work proactively to address requirements-related risks. As is well known to practitioners, most projects do not address the risks they face with the discipline that they should. There are many excellent books concerning how to do this. A good starting point is Chapter 11 of [15]. Another source is [9], which provides a chapter on software requirements and risk management. Table 5 describes typical requirements-related risk response strategies that should be helpful.

Table 5: Suggested Requirements-Related Risk Response Strategies

Summary

From my experience in working with projects of all sizes, there is a lot of benefit to investing in and continuously improving the project’s requirements process. There really is no good excuse for the extent of rework that is typically required on projects, or for the failure of projects, or even delivery of reduced functionality and/or over budget or beyond schedule issues. It is within our power to do better. Use of one or more of the requirements basics discussed here is likely to be helpful. Consider discussing the contents of this article at a project staff meeting with the objective of identifying the top three ideas, suggestions, or recommendations to improve the requirements practices of your project.

Dr. Ralph R. Young

Do the common project life cycle principals apply to the average Open Source Software project? Do OSS projects go through the phases ofdefinition, planning, organising, execution and closure? It is perhaps not quiteas formal, but if you look hard enough the same phases of the developmentprocess can be found in all OSS projects. Whether it's conscious orsubconscious, OSS projects all follow the common development stages. In fact itcan probably be argued that the successful OSS projects follow these principlesintuitively and instinctively. Good project management practices really can make the difference between successful and unsuccessful OSS projects.

Take for example the appointment of a project manager. The majority of OSS projects don't formally appoint an official project manger, yetin most projects you will find someone taking on the role of project manager. Heunderstands the significance of the development process and the importance of leading a good team.

So what is it that an unofficial OSS project manager might bring to the successful OSS project? As mentioned earlier, the project managercan't ignore the familiar stages making up the common software development process:

1. Project Definition
2. Planning
3. Organising
4. Executing
5. Closing

However, following this development process amounts to very little if the project manager has little understanding of the key leadershipskills involved. The ability to specify precise goals, to communicate clearlyand to motivate members of the project is crucial to the leadership. In the OpenSource environment, the motivation of the team members presents the realchallenge. The familiar financial motivation plays no part in many open sourceprojects. For most developers working in an OSS environment, you will probablyfind the following motivators having the biggest impact on the project:

• Achievement
• Recognition
• Responsibility
• Advancement

None of these motivators are tangible, but you have to pay close attention to them in OSS projects. It is easy in commercial projects toover look these points and focus on the more tangible motivator known as money.If you want a truly motivated team though, concentrate on both the tangible and the intangible motivators!

Even in the apparently chaotic world of open source software development, clear process and good leadership are essential tenets. The processmay be more fluid in an OSS project and the leadership less formally defined,but both aspects are just as important all the same. In the following sectionswe will look at the stages of the project development process in the OSS context and see how team motivation plays its part in each of these stages.

Project Definition

"Project Definition" sounds very formal, but its importance can’t be too highly stressed. The problem definition influences everything within your project. Whilst working on an OSS project we may not formally document that we need achieve X and Y, but in many cases the objectives of an OSS project are far clearer in the minds of the OSS project team than that of the commercial software development team.

In the case of a commercial software development team, you might typically have someone define what needs to be achieved and then communicate that vision to the development team, hoping that they understand it. In the OSS scenario, you typically have a group of developers that have come together because they have all experienced, first hand, the "problem definition". This makes it is far easier to understand the problem and see a route to the solution.

Defining the 'problem' and specifying the requirements isn’t always straightforward. However, this is where most OSS projects have an advantage over their commercial counterparts. By far the best way to understand a requirement is not to read it, but to experience it. Most OSS developers have experienced the need to fulfil a particular requirement. After all, coming up against the problem is probably the main reason they've picked a particular OSS project to work on in the first place. Experiencing the need for a requirement first hand will always provide a better understanding than reading a written requirement specification second hand.

With a clear definition of the problem you are already ahead when it comes to motivating the team. Having a clear goal is absolutely key to engendering a feeling of achievement as the project evolves. You can only feel like you’ve achieved something, or that you are progressing, if you know what you are aiming for. So make sure you define the project and that you communicate that definition clearly to the rest of the team.

Planning

When you think of Open Source projects, formal project planning isn't one of the first tasks that spring to mind. Open Source projects have a reputation for a slightly more ad-hoc approach to planning. Maybe the OSS approach to planning isn't formal but, believe it or not, it is still a step that needs to be taken seriously. The OSS projects that succeed may not have formally defined project plans, but you can guarantee that the team has an instinctive ability to plan and organise their work.

The almost religious reliance on defect tracking tools (e.g. Bugzilla or Mantis) is possibly one of the reasons OSS teams are so good at identifying and organising tasks. In the OSS environment, the teams defect-tracking tool turns into far more than just a tool for tracking defects. It becomes the foundation that helps to organise and priorities the work of the whole team. It tracks everything from release tasks, defects, enhancement suggestions and, sometimes, even the to-do lists of individual developers. The defect tracking system’s effectiveness at prioritising and assigning tasks comes into its own within many OSS projects. Without the pressures of deadlines, the complexity of tools like Microsoft Project can be left behind for defect tracking tools that are far easier to implement and run.

The use of system architecture and design definition is possibly the weakest link in this comparison with formal project management.Whilst in commercial projects it is common to see reams of paper specifying thedesign of the system, it is not common to see this sort of work on an OSSproject. In a typical OSS project, it is common for design ideas and concepts tobe quickly prototyped in code and distributed to the community for feedback andcomment. Even if it is perhaps not the most efficient use of time and resources,this proves to be an effective mechanism for identifying what should and shouldnot be included in the application. Personally I advocate a least a certaindegree of formal design work before coding begins. Formal design specificationsadd clarity to the project and help foster a feeling of advancement as the project progresses.

It is during the planning phase that serious consideration needs to be given to matching the goals of the project with the goals of theteam members. One of the key reasons people get involved in OSS projects is toimprove their skills and experience. If you decided to implement your projectusing Pascal, you would likely limit the pool of potential developers to work onthe project, or even empty it. If, however, you select one of the more popularand exciting technologies, you are more likely to attract and retain coders onyour project. Again the feeling of advancement whilst building and developing new skills helps to create an environment of motivation.

Organising

The OSS team usually excels at this stage. The ability to bring together the team members, the tools, controls and communications methodsto get the job done are second nature to most OSS teams (partly because theyknow exactly where to turn to for OSS solutions to address these issues andpartly because that are no organisational restrictions imposed on theimplementation). A typical OSS team thinks nothing of implementing the toolsneeded to run the project efficiently. Setting up a defect tracking system, a forum and source code control in days if not hours.

The difficult, and perhaps crucial part, is how you open up these tools to the community. Do you open up your defect tracking system toabsolutely everybody? Thereby exposing yourself to perhaps hundreds of poorlywritten, invalid defect records which all need sorting through. Do you provideeasy access for new members of the development team to the source coderepository? People who have no track record on the project could make critical changes to the code base.

I witnessed a recent exchange on an OSS project forum where a new member had been busy checking in code changes to the CVS repository. He hadrenamed fundamental aspects of the application because he thought he knew betterabout the terminology that should be used. This demonstrated how easily extra,unnecessary work can be created if you don’t get the project controls right.It is difficult to get it right as to whom, how, when and where you open up yoursource code repository. Yet getting it right is essential to the success of the project.

It is essential to get the balance right between restrictive controls and the freedom that helps motivate the team. If your controls aredraconian you stifle enthusiasm and motivation. If you loosen controls you mayfind it easier to develop the levels of motivation. Giving your team moreresponsibility makes a big difference to the project and can be incrediblymotivating. There is nothing complicated with principals, but never underestimate the importance of getting the balance right for your project.

It comes down to making the right decisions in involving the community you are serving and keeping the control and direction of the projecton the right path. Like many things in life, the solution usually lies somewherebetween the two extremes and can depend largely on the maturity of the project.Never forget though, that passing on more responsibility can be a powerful motivator.

Executing

You would think that the coding stage would be a walk in the park for most OSS projects. After all, we're all supposed to be good at this thepart. Yet the success of this part of the project is largely dependent on thefoundations built in the previous stages of the project. If you don't have aclear understanding of the problem you are solving or your prioritisation of thework was short of the mark, you limit the chances of success. Good coding alone doesn't make a successful project.

Assuming that the foundation stages have gone well, it is this stage where the "release early and often" approach is often citedas being the key to a successful OSS project. However, I would argue that an OSSproject that relies solely on the community for its unit and system testing isasking for trouble. I recently upgraded to the latest version of a popular Linuxoperating system. Maybe it was my fault for not reading the release notesproperly, but by the time I realised that they’d stop supporting a populardatabase that I relied on it was too late. Yes they released early, but I hadalways found previous early releases reliable and became complacent whenupgrading. This taught me a valuable lesson regarding complacency and the deployment of OSS.

There is a balance to get right here, especially now that more and more people are starting to rely on OSS. If you continually release buggy software in today’s environment, you risk losing users. You can't expect users to test everything for you. With so much choice around now (I’ve lost count of the number of Linux distributions now), users will remain loyal only if you reach a certain level of quality before release. If you abuse the loyalty of those users, then you’ll have fewer users to further support your testing efforts. With fewer users you have less testers and you enter a slow but lethal spiral of death. Get it right though and you can expect a faithful, loyal following of users.

Feedback from users is another absolutely crucial aspect to the execute stage. Few OSS projects enjoy the privileges of a dedicated test team that is paid to give you feedback. This presents two key problems

1. the test team / users won’t be physically located near you
2. the users / testers aren't obliged to give you feedback.

To a large extent the feedback you get is down to two things

1. how easy you make it for people to provide feedback
2. how supportive you are to those people when they provide feedback.

This bit isn't difficult to understand. If they can't provide you with feedback (i.e. you don't give them a usable feedback channel) you won't get any feedback. If you don't thank your users/testers or you aren't grateful, then they won't provide you with feedback a second time round. More than commercial projects, OSS projects live and die by the feedback they receive from users, because they have no internal feedback mechanisms or internal test team to rely on.

Forums are among the best feedback channels and the most powerful motivators for OSS projects. Forums are so powerful that I find it difficult to understand why commercial projects don't use of them more. Perhaps it’s the thought of airing your dirty washing in a forum that puts commercial projects off using forums. Yet, if a developer in a commercial project receives negative feedback about his/her work in a forum, you can almost guarantee that he/she will feel motivated to do something positive about it. We all crave for feedback and recognition. Feedback through forums can satisfy those cravings.

Take, as an example, the last time you ate at a restaurant and complimented the waiter for a really delicious meal. The chef cooked themeal but we compliment the waiter. How do we know that the compliment was sentback to the chef? Wouldn’t it be more rewarding for the chef if he wascomplimented in person? It’s no different in software development, as forumscan provide that direct channel between the users and developers. A forum islike standing up in the restaurant after finishing your meal and shoutingthrough to the chef in the kitchen that you thought the meal was delicious. Notonly does the chef receive your complement directly, but you’ve also told therest of the dinners in the restaurant what you thought about the meal. That’s a huge motivator for the chef.

Closing

Of all the stages, this is the one that is very different to that of a commercial project. Getting it right can make a huge difference to theoverall image of the project. You don't have to provide documentation. You don’thave to provide any support. You don’t have to make sure all defect fixes areverified before release. In a typical commercial project, you will not achievesign off until all of these aspects are complete. Yet many people fail torealise that if you don’t complete these aspects with OSS projects, you areforcing your users to jump though many unnecessary hoops, which is likely to mean less users.

The Apache foundation is a really good example of completing the documentation successfully. People actually come forward to volunteer towrite documentation for this project, because they receive kudos and recognitionfor their efforts. In smaller and less successful projects, this can be howeveran extremely difficult step to complete. Nonetheless, without good documentationit is very difficult to call an OSS project a success. Users are so dependent onwell-written documentation. Imagine trying to use CVS without a well written user guide… it wouldn't be impossible but it would be far more difficult.

It is also during this phase that the feeling of achievement comes from knowing you’ve solved the problem defined at the start of theproject. This is why it is so important to define the problem in the firstplace. When members of the team know they’ve solved the problem defined at thestart, they know they’ve been part of a successful project. It’s importantto remember that a successful project is defined as much by the members of the team working on the project as it is by the end users.

Conclusion

Recognition, responsibility, advancement and a feeling of achievement all play a crucial part in keeping a team motivated. It is thatmotivation that plays one of the biggest parts in making a project a success. Noamount of project definition, planning and organising will achieve anything ifyour team isn’t motivated. Yet every stage of a project presents opportunitiesfor you to motivate your team. Whether you are running an Open Source project ora commercial, closed source, project, you should take every single one of theseopportunities to motivate you team because this will ultimately create successful projects.

William Echlin

XPM is based on a highly successful software delivery process called Extreme Programming (XP). XP was developed fairly recently in response to problems that plagued other software development processes.

XPM is an adaptation of the practices of XP from software to other fields like architecture.

This paper provides an overview of XPM from a practical "how to" viewpoint. I'll list the XP practices and talk about how to use them in architecture for planning and quality control. I'll cover topics only briefly, with the intent of expanding on them later.

My Experience With XP

I'm both an architect and software developer. I had been writing software for over ten years before XP was introduced. To make a long story short, I started using XP practices and it literally changed my life: I was able to derive solutions faster. I was confident the work I did was right. My work improved continually. Bottom line: I produced much better work and took less time to do it.

Over time, I started thinking about adapting XP practices to architecture. This paper is the result of that thinking. XP practices can be readily and beneficially adapted to architecture. This paper shows how.

Extreme Programming

XP is a popular and effective software delivery process. Although developed fairly recently, XP has already attracted a large following of software developers, managers and customers. Its appeal for them: it works better than other software delivery methods.

XP is team-oriented and customer-focused. Teams range in size from small to medium with the customer as an integral part of the team. XP practices help the team determine and deliver exactly what the customer wants, even if the requirements change over time. The practices also insure that the team delivers high-quality error-free products.

Underlying XP are the values of simplicity, communication, feedback, and courage, which you will see evidence of in the practices themselves.

That's all I want to say about XP for now because I want to focus on XPM. There is plenty of information available on XP: at least seven books with more in progress, web sites, discussion groups, news groups, seminars, consultants and more. A good overview of XP is at www.xprogramming.com.

XPM Practices

XPM practices can be divided into two types: planning practices and quality control practices. Planning practices consist of the Release Plan and the Weekly Plan. The rest of the practices focus on quality control and are used daily.

In this paper, I'll first address XPM planning practices, then XPM quality control practices.

XPM Planning Practices

One of the cornerstones of XP is simplicity, and XPM follows suit. XPM planning practices are simple. You don't need critical path methods or project management software. All you need are index cards and common sense.

Here's an overview of how to run an XPM project:

• Create a release plan
• Each week, create a weekly plan based on the release plan
• Each day, do daily tasks based on the weekly plan

Release Plan

The first step in running an Extreme project is to create a Release Plan. The Release Plan describes all the work to be done for the current project phase. It is usually created by the project manager, aided by team members, before work begins. Create a separate Release Plan for each work phase: schematics, design development, contract documents, etc.

Here's how to create an XPM Release Plan:

• Think through every task required to complete the work.
• For each task, write a brief description on an index card.
• Estimate the time required to complete the task and add it to the card.

When you have a card for every task, you've finished the Release Plan. The Release Plan is just a stack of index cards.

Here are some planning guidelines:

• Make a card for every task you can think of.
• No task should take more than 3 days. Break large tasks into sub tasks.
• Each task must be testable. You must be able to verify that the task is correct and verify that it is complete.
• Estimate time in ideal hours, that is, the number of hours it would take if you could work continuously without interruptions.
• Make task descriptions brief, not detailed. Tell what, not how.

The Release Plan is not cast in stone. It can and probably will change during the course of the project. Time estimates are not fixed either. They probably will be modified by the team members during weekly planning meetings.

Release Plan Recap

A detailed Release Plan is easy and won't take long to create, even for a large project. You can use spreadsheets, prior projects, and checklists to facilitate the process.

For more information, see release planning tips.

Weekly Planning Meeting

The Weekly Planning Meeting is an integral part of the XPM planning process. The purpose of the meeting is to assign the week's tasks. All team members attend. The meeting usually begins with a retrospective, which I'll talk about later.

It is important that the time interval between meetings be consistent. Meetings should be held weekly, at the same day, time, and place each week.

Prior to the meeting, the project manager selects tasks for the week. Task cards for work remaining are usually arranged on a table in stacks, by priority or by weeks. The PM goes through the stacks, chooses the highest priority tasks, and brings them into the meeting. The number of tasks selected should be based on the prior week's velocity.

Velocity

Velocity is the number of points (ideal hours) completed by the team per week. The idea behind velocity is simple: If a team did 100 points last week, it will do 100 points this week.

The concept behind velocity is this:

• If you use a constant time interval between planning meetings,
• and if you use a consistent way to measure task difficulty or time,
• then you can calculate a consistent measure of productivity: velocity.

Two powerful features of velocity:

• Velocity tends to remain constant over time.
• Velocity self-corrects for interruptions, under-estimating, over-estimating, meetings, pairing, and other inefficiencies.

When calculating velocity, only completed tasks are counted. Determining whether or not a task is complete will be discussed later when I talk about testing.

Assign Week's Tasks

Back to the planning meeting. The objective is to assign tasks for the week.

One by one, choose, read aloud, and discuss each task card. Purpose of the discussion is to:

• Clarify what's required and expected
• Break down tasks into sub-tasks if necessary. No task should exceed 8 hours at this point.
• Validate or re-estimate the time required

After all cards have been reviewed, organized, and placed on the task board, team members begin signing up for tasks by posting a selected card beneath their name. When a task is complete, they update the time estimate, put the Task Card in the "Done" pile and select another card.

Weekly Plan Recap

The Weekly Plan corresponds to the Iteration Plan in XP. We call the time interval an iteration.

Planning Recap

We've briefly discussed the Release Plan and Weekly Plan, two simple practices to assure that appropriate tasks are identified, assigned and tracked.

Before moving on, I should mention that new task cards must sometimes be added during an iteration. They usually represent high-priority tasks that can't be delayed. They are discussed and estimated during a stand-up meeting, and posted as before. Lower priority tasks of similar duration are removed to compensate.

Now I want to talk about the daily XPM practices. They help assure that tasks are done efficiently and correctly.

Daily Practices

Daily XPM practices help keep the team aligned, focused, and informed and help insure that tasks are done efficiently and correctly. The practices are integrated. Like concrete reinforced with steel, they are designed so the strengths of one compensate for the weaknesses of another. As a consequence, an XPM practice can't be ignored. If you can't follow an XPM practice, you should substitute alternatives that provide similar benefits.

One of the most important of the XPM practices is testing.

Testing in XP

In XP, you test "everything that could possibly break". Tests are automated so they can be repeated each time you make a change.

Testing is best feedback mechanism there is. Its results are immediate, unbiased and accurate. Without testing, XP simply would not work. XP values testing so much, it mandates that "no code is written without a test".

Testing Alternatives in XPM

XP won't work without testing, nor will XPM. For every task, we need to be able to determine:

• Is it correct?
• Is it complete?

However, architects can't test the same way programmers do. When we can't test directly, we must devise alternatives such as:

• Test lists
• Examples
• Prototypes
• Standard details
• Mistake-proofing
• Standard forms
• Meeting agendas
• Form letters
• Peer reviews

To simplify this discussion, when I talk about tests from now on, I am including testing alternatives as well.

Project Tests and Task Tests

In XPM there are two types of tests:

• Project Tests: created by project manager, perhaps assisted by team members, to assure that overall project goals are met.
• Task Tests: created by team members to assure that tasks are correct and complete.

Example:

• A Project Test might require that stair detail conforms to code.
• A Task Test might require that tread be 11", riser 7".

One Test at a Time

In XP, code is written test-first:

• Write a test.
• Write code to make the test pass.
• Write another test.
• Repeat. If you can't think of any more tests, you're done.

This process is called Test Driven (or Iterative, or Incremental) Development in XP. Based on using feedback to determine the next step, it's a very effective and timesaving practice for developing software.

A similar process can be used for developing XPM tests in architecture. Instead of writing a comprehensive list of tests for a task, we would instead determine the minimum effort that would satisfy the requirement. If that is insufficient, ask what else is required, and continue until all requirements are met.

Iterative Development may not be as quite as important to architects, however, because most of our work, at least in the CD phase, is repetitive.

Architects' Advantage: Repetitive Tasks

Most architectural projects follow the same or a similar path. We know we'll have to draw door and window details, research products and materials, write specifications, and prepare a cost estimate – no matter which project we are working on. The same tasks are repeated on each project. Thus, we have two advantages. We can:

• Re-use tests on other projects.
• Share tests with colleagues.

I'll discuss how to maximize these advantages at the end of the paper.

Testing Recap

Testing provides instant feedback that what we've done is correct and complete. There is no better mechanism to give us that level of confidence. Where we can't provide automated software tests, we can develop alternatives. It's a wise investment because our tests can be used both now and in the future.

Other XP Practices

In the following sections, I'll briefly mention some other XP practices. They help keep the team aligned, focused, and informed. Most can be adapted directly to XPM as-is.

Pairing

In XP, tasks are completed by pairs, not individuals. Two people work together to complete each task, switching pairs frequently. Pairs also work together to create the tests and verify that they've passed.

Pairing may seem like a duplication of effort, but consider the alternatives. In order to achieve the same level of quality, communication and knowledge transfer, you need more meetings, memos, notes, emails, standards, and other office artifacts; all of which are time-consuming and difficult to sustain.

All in Same Room

Everyone working on the project works together in the same room, with visual and vocal contact.

Continuous Integration

In XP, you are expected to maintain a complete, working, end-to-end system at all times. Other than stubs, which are place holders for unimplemented features, everything included works correctly; otherwise it's not included.

Example in architecture:

• Every component of the design, as represented by the deliverables, must be complete and correct at all times.
• If an elevation is changed, floor and roof plans are changed to correspond.

Collective Ownership

Everyone owns all the documents. Any pair can make changes as long as the tests still pass. Working in pairs insures that changes are appropriate.

Examples in architecture:

• Pair with spec writer to change specs
• Every team member is permitted, and expected, to change any component of the drawing set: plans, elevations, sections, details, etc.

Office Standards

XP requires teams to agree on and adhere to a set of standards. However, standards are added only as needed and unused standards are eliminated. In other words, standards, although required, are kept to a minimum. For example, instead of a detailed written standard, provide an example, annotated if necessary. Require that all work look like the example.

Refactoring

XPers "refactor" existing code to remove duplication and make their intent more clear. All tests must pass before and after doing a refactoring. To reduce oversights, refactoring is done in pairs. Tests and processes can be refactored as well as deliverables.

Retrospectives

Retrospectives are held at frequent intervals in order to identify and modify processes that aren't working effectively.

• Weekly Retrospectives: Begin weekly planning meetings with short retrospective.
• Project Retrospectives: Conduct longer retrospective after project or substantial milestones have been completed.

Stand-Up Meetings

Stand up meetings are held frequently to facilitate communication and keep team members informed.

• Daily Stand-Ups: Start each day with a short stand-up meeting. Each team member describes work on current task, identifies potential problems.
• Ad-Hoc Stand Ups: Anyone can call for a stand-up to discuss a pressing issue.

Project Charter

Before beginning each project, the entire team meets to discuss project goals and priorities.

Sustainable Pace

Team members work hard and at a pace that can be sustained over time. They rarely work overtime.

Big Visible Charts

Display important information in a prominent location, for everyone to see. We post all task cards for the current iteration on the task board. Everyone can see who is working on what, what tasks have been completed, and what tasks remain.

We usually post a project progress chart. It charts the number of points completed and remaining after each iteration. The slope of the chart can be projected to point at the completion date.

On-Site Customer

Customer is available at all times to answer questions, make decisions, offer feedback.

XPM Architectural Practices

Some XPM practices are unique to architecture. As with XP practices, they help keep the team aligned, focused, and informed.

Prototypes

We use prototypes, in addition to standards, to insure consistency and establish a level of quality. Prototypes are like standards adapted to a specific task. For more information, see using prototypes.

Working Cartoon Set

From day one, we provide a model of our final objective, updated as we progress. We can instantly see the work we've done and the work that remains. For more information, see working cartoon set.

Practices Recap

I've discussed the most significant XP practices, listed their benefits and talked about how they can be adapted to architectural project management.

XP practices evolve over time. The XP community is very active and all XP practices are subjected to intense scrutiny and discussion. Similar scrutiny should be applied to XPM practices as well, not losing sight of our real objective: to efficiently produce high quality work.

Future of XPM

I'd like to see:

• Architectural teams using XPM practices and sharing results.
• Teams creating and sharing test alternatives.
• People discussing XPM issues with as much vigor and enthusiasm as the XP community.

Making it Happen

To help make it happen, I've set up the following:

• A mailing list, managed by Google, to inform readers about new articles and revisions on these web pages. Go to http://groups.google.com/group/Architectural-Practices and follow Google's instructions.
• An open discussion group, managed by Yahoo!, to discuss architectural practices at http://groups.yahoo.com/group/architecturalpractices/.
• This web site to collect and share materials on XPM. www.architecturalpractices.com.

As a project manager, you have three classes of natural enemies:

Luckily, only the third category really matters. The higher-level management decides on your salary, on your future assignments, on your career. Consequently, you need to direct all your attention to the higher-level management, or more precisely to the impression you make on the higher-level management. Doing good project management is one way of creating a good impression, but fortunately there are easier ways of achieving that goal.

The customer is often referred to as the counterpart of the project manager. This is wrong. The customer is only a minor figure in the game. In principle, it doesn't matter whether he is satisfied or not, whether he is happy or not, or what opinions or feelings he has about the project manager. The only significance the customer has at all, is in his impact on the higher-level management, and, contrary to popular belief, the fact is that the impact is negative if he is treated too well. The higher-level management will think it's child's play to run a project with such an easy-going type of client, whereas it must be your goal to make them believe that only your heroic efforts could bring any amount of success dealing with such a trouble-seeking customer.

Don't make it look easy.

Having a satisfied customer is a dangerous thing

Satisfied customers belong to the mission statement, where they cannot do any harm. Avoid them in your projects at all cost. One has to be realistic. Who will be assigned to manage the next project: Project Manager A, who can manage trivial projects, but has never been challenged in difficult circumstances, or Project Manager B, who shows some degree of success even when confronted with extremely hostile customers?

Additionally, an overly satisfied customer will always generate the impression, that your loyalty to the customer is higher than your loyalty to your company. Allow this, and you are looking for a job.

Serious mistakes can be made in the planning phase, as this is the stage to foresee future difficulties, and prepare for them accordingly.

Never get involved at the very early phases

Nothing can be gained by joining a project too early. Medals are being distributed at the end, not at the beginning. If you join later, you can always claim that things were messed up at the initial stage. No-one will remember exactly.

Plan most tasks to be finished just before the last milestone

Too many people can read Gantt charts. Task end dates are like mini-checkpoints and the very last thing you need are umpteen checkpoints on which anyone can put his finger. Combining most of these checkpoints with the unavoidable last milestone gives you the much needed degree of freedom to interpret the progress during the project.

Use person-years as estimation unit

It is in your interest to use the most ambiguous unit when estimating the effort, so that you can do some adjusted form of reverse calculations when needed. Avoid any detailed clarifications on what a person-year stands for, such as whether holidays or non-project overhead are included or not. If someone asks, say you used the standard definition, and therefore it's unnecessary to write it down.

Add contingency at all levels

Contingency is your little friend and helper. However, you must be aware that removing contingency is the only contribution of higher-level management to project planning. Therefore, it is essential to add plenty of contingency in many different forms, so that you will have enough after the removal. You have to ask the engineers to add contingency in their estimates, which later you refer to as "raw figures". Participate in all estimation meetings in order to talk the figures up. Then add contingency both in percentages and as extra activity at task, module and project level. Finally you add risk premiums at the various levels. The key skill here is creativity in naming, as you cannot expect any mercy from higher-level management when they recognize contingency as such.

Incomplete and ambiguous requirements are often said to be the most common obstacle to project success. That may or may not be true, in any case that's not your concern. Your concern is more the project manager's success. To this end, incomplete and ambiguous requirements are, generally speaking, quite helpful.

Never ask for completion of obviously missing requirements

Obviously missing requirements are the basis of your bonus. You can include them in your planning, and when the gaps in the documents surface later on, use them to justify all that extra effort that accumulates naturally during a project.

You have to be a bit more careful when it comes to ambiguous requirements. Skilful professional judgment is required to find the optimal point in time when to address them. Some can be used as a reason for early delays, as it takes time to clarify them, others can be helpful in drawing attention away from something else at a convenient moment, still others can be helpful in justifying poor implementation at a late stage.

The problem with risks is, that the project manager is expected to manage them. That would be hard. Therefore, if you see any risks in the project, make sure they don't appear as such in the project plan. Fortunately, there are more suitable places in typical project plan templates.

Hide risks as assumptions

It would be a mistake not to document those risks at all. You could be asked, "why haven't you taken care of that?" Assumptions are the perfect place for risks. No-one was ever asked to manage assumptions. Of course, a little rewording is required, by saying "it is assumed that such and such will not happen". If the thing goes wrong, you can always say that the project started under different preconditions, and that this was agreed with everyone beforehand. You don't need to be afraid that it will not be agreed. Nobody ever reads these boring parts of the project plan in a review.

Make sure to keep some easy-to-manage risks for the risk table, otherwise people could get suspicious. Furthermore, as we have seen above, you need risks to justify the risk premiums, and you need some easy risk-related activities to fill your progress report.

After the inevitable removal of the contingency discovered, as mentioned above, don't forget to add "best-case planning required by management" as top risk. You are safe in not adding any risk aversion action to this one. As a matter of fact, quoting that risk is only a small favor you can do for higher-level management, who like to be pictured as brave managers, determined to take risks if necessary.

Status reports are a project managers appraisal sheets, and it comes in handy, that these are written by yourself. It would be a pity not to use that to its full advantage. Besides the obvious acclamation of any real or plausible sounding achievements, one has to follow just a few simple rules.

Never report delays as long as it makes sense to stop the project

This is one of the basic principles for successful project managers. Nobody stops a project that is 80% completed because of a 30% budget overrun. That's quite different in the first half of the project. Fortunately, this principle is dead easy to follow, as it just requires not doing something. Fill the time in the steering meetings with success stories and complaints about the customer. That should be sufficient to convince higher-level management that these meetings need to be short.

Never report delays as long as there is a chance that someone else has to

If you have a delay, wait until some external deliverable doesn't come in time. When that happens, your own delay to be enforced is calculated as the external delay plus your replanning time. The replanning time is never less than two weeks. If you need an external delay urgently, ask the customer to provide some clarification till the end of the week. Then say it's insufficient.

Multiply enforced delays by team members

There is a strikingly simple formula to calculate the budget overrun from an enforced delay. Just multiply it by the headcount in your project, no matter how many people are actually affected by the delayed deliverable. Even avoid that concept of "people affected" in your reports, and rely on the sheer beauty and simplicity of the argument.

In progress reports, only report actuals and planned totals

Project tracking is comparing actuals with plans. What you have to avoid, however, is comparing actuals with up-to-today totals, as this would mean comparing apples with apples, which in turn could lead to dangerous conclusions. You have to start this practice at the beginning, when it doesn't really matter yet, and later when people start to complain, say it's the way it was always done and it would be unwise to change reporting procedures in critical phases of a project.

Call it extreme project management

This is a Jolly Joker explanation. Whenever you fail to come up with a good enough reason for anything, tell them you are applying extreme project management. Never get involved in discussions about details here. If someone insists and asks what exactly that means, or wants to know why that would be appropriate, then just refer them to "the literature" and advise them to learn a little more about modern management methodologies before one can continue such a discussion.

If milestones were supposed to be shifted around they would be called pebbles. Just like a week is a week, no matter what happens, a project phase has to end when the time is there, no matter what has been accomplished. The purpose of a milestone meeting is to celebrate the achievements of the passed project-phase with a glass of champagne or coffee and donuts, whatever your company's style allows.

Occasionally, people have the notion that the passing of a milestone needs to be "decided", as if the passing of a year needed to be decided. That rarely comes from higher-level management, as they love their champagne, but if it does, you have to be careful. In that case, you discuss whatever issues they bring up at length and then, while they pour the champagne, say you will document the decisions in the milestone report.

Report vague results of milestone meetings

No questions, the milestone is still passed, but you have to bring in the higher-level management objections in a constructive way. You do this by using some attributes, such as calling the milestone "conditionally passed". Don't list any conditions in that case, that could later be used against you. Another variant is calling it "provisionally passed", or something along those lines, just make sure you can refer to the milestone as "passed" in the next meeting.

Re-used modules are blame-tickets. Make sure to re-use plenty of code from previous projects, the more the better. Then track all the difficult bugs to some re-used code, even if the code was never intended to be used the way you use it. As the code comes from a team that doesn't exist anymore, it's as easy as winning a tennis match against a ghost. The good thing now is, that you can still prove that despite all these bugs, your decision to re-use was right, because writing all that tons of code from scratch would have been prohibitively expensive, so you saved an enormous amount of money.

No-one was ever accused of having too much re-use

Another brilliant aspect of code re-use is, that a fair amount of extra costs can be justified by claiming that you make your code re-usable. Ideally, of course, your code will never actually be re-used, but even if it were, you wouldn't be there anymore. It also wouldn't make a difference to your bonus, because no higher-level manager has ever been known to distinguish between re-usable code and re-used code.

Never mention the project team in communication with higher-level management. Talk about you, or at most talk about "the project". The team is just a tool to accomplish some work, and you don't talk a lot about your hammer, do you?

Don't be popular within the project team

On the other hand, make sure the team talks about you whenever they happen to communicate with higher-level management. Furthermore, make sure they don't spread the impression that they like working for you. A project manager is not being paid for making the project team happy. If they are, it is always seen as an indication that you are unable to squeeze the last bit of productivity out of them, which is one of the worst things that could happen to your reputation.

Project end dates could be treated like other milestones, if it weren't for the peculiarity of product shipment. The principle of immovability still holds, but creativity may be needed for the delivery part. If the product isn't finished, you can still ship it, as long as you make sure that it's also untestable. There are a number of techniques to achieve this, which all have in common that they exploit properties of the test environment. You can make the product uninstallable, or you can make use of a limitation of the operating system, the platform or the database that is used, so that it won't run. These considerations cannot, of course, be left to the last minute. It must be a top priority task of your best engineers to identify these shipment variants before they build the product, and it must be a guiding design principle from the very beginning.

Declare your uncompleted project as finished

Whatever the outcome of the attempts to test the product, after the final shipment, there must be no such thing as an open task. That's easy to achieve, because, after all, it's the project manager who decides when a task can be considered finished. The only things that are left after you close all tasks, are the so-called "follow-up activities". These are, however, much better taken care of outside the project, for instance as "maintenance" under the supervision of line management, or within the next project, as long as it isn't yours.

It is rarely necessary to point out to higher-level management how wise it is to close the project as long as it is still possible to call it a huge success. They wouldn't be higher level if they wouldn't know the advantages of having successful projects within their area of responsibility. Keeping those simple tactics in mind really creates a win-win situation for everyone.

1. Natural enemies of a project manager
   • the customer
   • the project team
   • the higher-level management
2. The customer is a mean to an end
3. Plan the planning
4. Requirements are not required
5. Risks are too risky
6. Keep the reports clean
7. Milestones are fixed
8. Embrace re-use
9. Your project team is not your electorate
10. All good things must come to an end

A few months ago, I watched a cable TV show which asserted that a Star Trek actor had changed the world. While the idea that William Shatner had single-handedly brought about the 21st century as we know it was funny, the information presented was pretty convincing that the science fiction show had a major impact on modern technology. Just call your bank’s voice-recognition computer using your flip-phone and … well, you get the picture. And it does not end with the original series; those reconfigurable, flat-panel touch screens that Geordi and Data sit in front of in The Next Generation can now be found in just about every fast food restaurant!

As I marveled at the effects a television series had had on our modern lives, I suddenly realized that most of the current software generation had grown up with Star Trek. I began wondering what effect this had on our approaches to software development and management. What I discovered I have termed The Gene Roddenberry Effect: Everything we do in software project management originated with Star Trek. I have developed a list of lessons learned from Star Trek that I regularly employ.

The Bridge Crew

One surprising example of how Star Trekhas affected software project management is how the composition of the bridge crew on the starship Enterprise reflects that of current software teams. In the original series, most of the stories centered around the bridge crew: Kirk, Spock, Sulu, Chekov, Uhura, Scotty (you know the names). Kirk was the ultimate leader and decision-maker, Spock was second-in-command and science officer, and all the others had specific job titles as well.

Modern industry has pretty much borrowed this structure for software engineering teams. Every project has a project manager (PM), a technical expert who acts as backup PM, a chief engineer, a communications officer (configuration manager), and so forth. The PM calls the shots, much like the captain (Kirk), and everyone else performs their particular jobs and regularly reports back to him. When the team has issues, it gathers in a conference room and projects everything on a flat panel monitor for all to review. The team makes a group decision, guided and ratified by Kirk. Watch those conference meetings in the original series and see if you get goose pimples at how similar they are to the meetings you go to each week.

Perhaps most surprising is the similarity between the bridge crew concept in conjunction with the Software Engineering Institute’s (SEI) Team Software Process (TSP). The TSP is SEI’s how-to guide for implementing high-maturity software engineering teams. In the TSP, each member of the team is given one of eight management roles. As I began looking at them, I was amazed at how closely they matched the bridge crew concept (see Table 1).

Table 1: TSP Roles vs Enterprise Bridge Crew

What is even more interesting is that many TSP teams actually do double up on roles as shown in Table 1. If they do not have eight people to perform the different roles, people take on more than one.

But wait; it gets even better.

Once we move to The Next Generation series, we find a whole new bridge crew with expanded roles. In this case, Picard, the captain, is no longer the PM, but has risen to the rank of senior management(as described in SEI’s Capability Maturity Model Integration 1.1). We can see from Table 2 that the team concept has matured aboard the newer Enterprise and that our more modern approaches to the software team concept have mimicked this structure.

Table 2: TSP Roles vs The Next Generation Enterprise Bridge Crew

We could go even further and examine the newer agile development methodologies only to discover that as the Star Trekseries matured, so did their concepts of teams and agility. Captain Janeway’s Federation/Maquis team aboard Voyager, for example, is the epitome of an agile team. In any case, whether or not it was done intentionally, it seems that modern software teams are indeed modeled after the Star Trek bridge crews. Some of the agile methods even measure a project velocity. A coincidence? Well, maybe.

Lessons Learned

So, with the obvious links between the Star Trek universe and the way we manage software projects, what else we can learn from Star Trek that can actually help us in our day-to-day management of software projects? The following are the 10 project management tips I use most often:

1. When push comes to shove, it’s always a computer geek who comes to the rescue! (Watch just about every Star Trek: The Next Generationepisode with Wesley Crusher.)
2. Your greatest challenges can be the ones you thought you got rid of 200 years ago. (Remember Kahn [Ricardo Montalban] from the original episode Space Seedand the movie Star Trek II? Remember Y2K?)
3. If everyone on your project is too happy, you probably are not accomplishing anything. (Yes, it’s the hippie episode about the spores, called This Side of Paradise. For those who are not ardent fans, trust us on this one.)
4. You cannot change the laws of physics, but you canbend them. (This is a line made famous by Scotty in the original series episode entitled The Naked Time.)
5. There is no such thing as a no-win scenario, especially if you change the conditions of the test. (This is Kirk’s philosophy and fits pretty well into his profile above! Watch Star Trek II – The Wrath of Kahnfor how this worked for him … or did not.)
6. Every successful project manager has both a good side and bad side and knows how to balance them. (Let’s just hope you do not beat yourself up the way Kirk did in The Enemy Within– literally. In that episode, Kirk had an evil twincreated by a transporter malfunction.)
7. Don’t feed the Tribbles or they will overrun you! (Substitute your own set of problems for Tribbles as seen in The Trouble with Tribbles. If you do not know what a Tribble is, why are you reading this article?)
8. If you do not apply a lot of power to break away from your routine, you are doomed to repeat the same mistakes over and over again for eternity. ( The Causality Loopfrom The Next Generation– great episode! Go rent it!)
9. Some people can be very afraid of change. (Let us just hope it doesn’t lead to the shedding of blood, red or pink as it did in the movie Star Trek VI – The Undiscovered Country.)
10. Always multiply your estimates by a factor of four so that you will be known as a miracle worker. (This comes from the movie Star Trek III – The Search for Spock, and we have no comment as to why this is number one or how we implement it; especially if any of our customers are reading this!)

Conclusion

While this article is a bit tongue-in-cheek, it’s amazing how closely our software engineering practices mirrorStar Trek. So live long, prosper, and remember to thank (or maybe curse) the great bird of the galaxy next time you put together those PowerPoint slides for your management review!

David R. Webb