Sizing UCD projects presents special challenges to usability practitioners and consultants. Each project and UCD methodology comes with its own set of variables that makes it difficult to accurately estimate resource requirements and completion times. Detailed descriptionNo matter how experienced a consultant is in sizing UCD projects, (s)he is continually faced with the challenge of effectively sizing a UCD project so that the actual end time spent on the various activities reflects what was originally proposed. The process of estimating the time it will take to complete any given phase of a UCD project, not to mention the entire project, may be affected by many variables, including the following:
Further, sizing is often an iterative process. Often a consultant will need to "take the pulse" of the project at various points, each time providing a sense of time and resource requirements. Thus, sizing a project is a critical yet difficult activity. Consultants and others responsible for sizing UCD projects have various strategies for providing clients estimates for UCD work. This paper will focus on two aspects of this topic: 1) Identification of why it is so difficult to size a usability/UCD effort, and 2) identification of strategies, including their respective pros and cons. Throughout this paper, we will use the term "consultant" inclusively to refer to those who provide usability and UCD services for clients (external consultants), as well as those who do so for groups within their own organization (internal consultants). How ToCommon Problems1. UCD is an iterative process.The number of iterations may be unknown. Ideally, in a user-centered design process, UCD consultants should be aware of the number of iterations planned for the design and development of a product, website, or web application prior to the inception of the project. Based on prior experiences, early formal and informal requirements gathering efforts, and other project definition activities, a consultant can determine how much iteration will likely be necessary to achieve a product’s objectives. However, if usability studies, for example, reveal multiple high-severity problems, then more iterations than originally planned in the development cycle could be the result. In turn, this will increase the amount of time and budget required to generate a usable design. The client may have a misconception about what an iteration entails. Usability consultants commonly think of iteration as being limited in scope. We conduct research and make improvements to the interface during early design phases, and make the interface incrementally "cleaner" with each iteration throughout the development cycle. However, a client may think an iteration means totally overhauling a design in its late stages. Or, the client may think that an iteration may equate to a software version where certain changes are made during version 1 and other changes are made during version 2, for example. Since software versions are typically larger in scale than UCD iterations, clients may think a UCD iteration is as large in scale as a software iteration. Once the consultant discovers that incorrect expectations have been set, contract renegotiation or client education may become necessary. 2. Budgets.The client’s budget may be unknown. Within a corporation, the budget for a project is quite often freely shared information. The usability consultant knows exactly how much the client is willing to pay for the project. Often this dictates either the specific activities the consultant can propose or makes it necessary to justify to the client the need to increase the budget. However, in the consulting world, clients frequently do not share their budgets with the consultant. Without knowing how much the client is willing to spend, it’s difficult to know the breadth and depth of activities to propose to accomplish the stated goals. 3. Client buy-in and knowledge of UCD.The extent to which a client ‘buys into’ and understands the UCD process affects the sizing. The client’s inexperience and lack of knowledge about UCD may cause the consultant to spend more time than originally planned to define and explain the importance of following a UCD process. The team members may not all be on board. Some team members may perceive that UCD adds time and expense to current activities and express ongoing resentment about having to follow certain procedures. If project team members do not possess a basic understanding and acceptance of the value of UCD, then it’s likely that those team members will present resistance at some point within the project, which will cause unforeseen delays and possibly additional expense. Clients may not understand the type of resource allocation necessary for UCD. Typically, more up front time and resource leads to less needed later. The budget may therefore seem unbalanced across the lifecycle of the project. Clients who don’t understand this might feel the need to try to cut corners during the times the budget seems excessive to them. In many cases, the team may have to go back and redo the work that resulted from the cut corners, thereby adding time and expense to the schedule and budget. Some team members may be UCD-savvy, but may not be domain-savvy. It may require some team members time to learn the application or website before being able to contribute 100 percent. This may contribute to schedule delays and increased expenses. Unforeseen team issues may arise. No matter how thoroughly the consultant evaluates the client in terms of their understanding and acceptance of UCD, inevitably a situation arises where one or more team members require special attention, requiring additional time not planned for or included in the proposal estimate. To ensure the project’s success, it’s critical to take time out to meet these needs. This takes time, which translates to dollars. Even if some education time is included in the cost estimate to "get everyone on the same page," there are occasions where team members may lapse into old thinking or practices. Additional time is required for regrouping. 4. Political issues.Buy-in may not be universal. Frequently, one department of the company may have ‘bought into’ the practice of UCD and it is typically those individuals with whom the usability consultant originally negotiated the proposed UCD project. However, frequently, ownership and responsibilities get transferred to another part of the company. Those individuals may not be ready and willing to accept and adopt the UCD activities originally proposed and signed off on by the other department. The consultant may have to back-track and spend ‘educational time’ not originally planned or budgeted for. Power struggles between team members can impact a project’s scope and estimates. One member may wish to exert his or her power and authority and opinions over those of other team members. Extra time may be required for the consultant to assist or wait for the client to work through the political issues. Sometimes managers are primarily coordinators and do not have actual control over team members or group decisions. If there is not a clear decision-maker for the project, or if the decision-maker does not have the authority to make the decisions stick, extra time may be needed to secure the consensus needed to more forward. 5. Scope creep.Projects tend to grow in scope. During any project, somewhere, sometime, someone will say something like, "ooh, it’d be really nice if we could just add this one small feature," or "could you also develop personas for the participants you used for that study?" Team members may lose sight of the fact that specific deliverables were identified at the start of the project, a budget was set, and a contract signed. Add-ons are just that: Things that add on to the schedule and budget. Establishing a feature review or change control process can help control this kind of scope-creep and ensure that each addition results in a resizing of the project. Content may need to change to fit a new design. The scope of a website redesign project could suddenly expand if the existing content supplied by the client for a website redesign project, for example, requires editing or reformatting to fit into the newly designed architecture. Even though the consultant may have stated in the proposal that the estimated costs do not include content revisions, the client may assume the content can simply be "dumped" into the new architecture, when in fact, it no longer fits. Reworking content to fit the new structure takes time, and must be budgeted for. Project management activities must also be sized. On small projects particularly, project management activities can become embedded within the project and are requested or expected of the consultant. For example, the client may expect the consultant to make changes to and update the timeline when the schedule must change due to the client’s inability to meet targeted deadlines. In some cases, clients may initiate frequent status meetings that were not included in the original plan and timeline. These bits of "administrivia" can add up to a great deal of time. Coordination of the elements of the total user experience requires time and effort. As usability professionals, we are concerned with the entire user experience, which means taking into consideration every touch point the user experiences with the product. It includes everything from unpacking the box containing a piece of hardware and reading the set-up instructions to referencing online support information to actually interacting with the software. Coordination of the design and development of the various elements of the user’s experience across multiple teams can require extra time and effort. If the consultant is working with marketing professionals who are creating the marketing materials, for example, and their efforts are not aligned with the goals of the user experience, then it may require more time for that alignment and possible rework to take place. 6. Ill-defined requirements.Like users, clients can’t always communicate their needs and wants in specific and detailed terms. They may not have spent the time necessary to develop clear, obtainable goals that can then be communicated to the usability consultant. Or, they may have preconceived notions about what is required to solve their ‘problems,’ expecting the consultant to simply deliver their already-pre-determined solution. The client team may not agree on requirements. In some cases, client representatives may express different or conflicting ideas about what needs to be accomplished. In turn, the consultant may have to spend unplanned time to assist in the process of the members reaching a consensus about the scope of the project. User requirements and business requirements may conflict. For example, a business may want to charge for a feature that users expect to receive for free. Ironing out misalignment of user and business needs can add time to the project (and occasionally change the nature of it). 7. The makeup of the team varies or can change.The UCD team makeup may change mid-project. The number of managers involved in making decisions, a change in management strategy, a change in the makeup of the team, company turnover, and other personnel issues can make the UCD team more fluid a body than originally planned for. Extra time is needed to compensate for these types of changes. Team members may be more or less efficient, skilled, or thorough. This affects the quality and timeliness of the deliverables. One member may be especially efficient in accomplishing tasks and meeting deadlines, whereas others may need to be managed more strictly to keep the project moving on schedule. Some team members may not have the skill sets needed to accomplish their tasks in a timely manner. The consultant may need to either educate the team member so that (s)he can complete the tasks or request the client reassign the tasks to others who are more experienced. In either case, the project will face a delay. Resources may need to be shared. Team members may be assigned to multiple projects, making it difficult to schedule their time or predict the effects this may have on the project scope. Priorities can change. As is the case in any corporate environment, employees frequently need to be reassigned to address higher priorities. It’s possible that a less experienced employee will join the project to fill the shoes of a more experienced team member who was reassigned to a higher priority project. The project may face a delay in order to bring the new team member up-to-speed. New (vs. established teams) may need more attention or time to get started. When establishing the project timeline and scope, the consultant may not know whether the teams have previously worked together and consequently may not factor in the additional time required. The participation of the client on the team can affect the project in unknown ways. The client may desire to have an active role in the project and have good intentions, but lack the time necessary to meet assigned deadlines. The consultant or others on the team may need to pick up some of the work to keep the project moving on schedule. In any project, there will be some level of conflict. Conflicts may be those of personality, scheduling, or disagreements about project details. Time taken to resolve the issues affects the project timeline and project scope. A client’s participation on the team may lead to the imbalance of power. For example, if the client happens to be a manager, his/her participation may intimidate others, leading to inefficiency. In other cases, power struggles between managers can affect the efforts of the project. 8. Other factors.These factors are initially or ultimately more important than the actual scope and time required to complete the project. Egos and competition between managers or companies may lead to unrealistic delivery targets. Companies often try to beat one another to production. In some cases, being first to market is driven by strategy. However, in other cases, personal agendas can drive schedules. Real project needs can become ignored in light of these agendas, affecting the project’s schedule and deliverables. Unexpected and catastrophic events may occur. Whether from a social, personal, or business related perspective, catastrophic events such ad the attacks of 9/11 may occur during a project and will affect the scope of the project in some way. As a consequence of the event, the project may need to be expanded or downsized to adapt to the circumstances of the event. 9. Insufficient or unavailable data at the time of project sizing.All the data needed to accurately and effectively size a project may not be available when the sizing occurs. An external vendor’s role in the project, for example, may have an impact on the ultimate size of the project and responsibilities of others. For any number of reasons, the necessary information may not be available at the time of the sizing exercise, making it difficult for the consultant to accurately size the project. Tools to be used may be unknown at the time of sizing. Professional methods or tools the corporation or client wants used for the project may be under development and not well-defined when the sizing must occur. Without the knowledge of the tools and their possible effect on the project, it’s very difficult for the consultant to take into consideration their impact on time and budget. Legal and governmental policies or changes may affect requirements. New legal requirements within the corporation or new state or federal policies that affect the way in which corporations conduct business or interact with their consumers can affect the original scope of the project. Facts |
|||