Scheduling UI Deisgn with Critical Chain Project Management
Upcoming SlideShare
Loading in...5

Scheduling UI Deisgn with Critical Chain Project Management






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Scheduling UI Deisgn with Critical Chain Project Management Scheduling UI Deisgn with Critical Chain Project Management Document Transcript

    • Scheduling UI Design with Critical Chain Project Management Revision 1.5 October 22nd 2004 Scheduling UI Design with Critical Chain Project Management By David J. Anderson Abstract UI Design and Usability Engineering can be fully scheduled into the program management activity of larger software development organization using Critical Chain Project Management (CCPM). The UI design group is used as the synchronizer in the CCPM multi-project solution and the throughput of UI design is used to regulate the flow (or velocity) of software development activities elsewhere in the organization. The work of the UI design group will be analyzed, scoped and estimated using the output from interaction design modeling with Visual Vocabulary or UML Statechart diagrams. The method can be used successfully with Agile software development methods such as Feature Driven Development (FDD). The UI design group is established as the managed constraint within the organization and the flow of value is regulated from the development of UI designs and specifications. Copyright David J. Anderson 2004 1
    • Scheduling UI Design with Critical Chain Project Management Revision 1.5 October 22nd 2004 Introduction Despite the bursting of the Internet bubble and the dramatic slowing of the economy in recent years, managers in software development businesses remain under pressure to reduce cycle times and deliver better, software faster. In tougher economic times, it becomes even more important to do more with less. The arrival of the World Wide Web did create many changes. One of those changes was the realization that good user interface design really matters. Businesses have come to realize that value is created and better realized through products and services with good user interface design. Software engineering has struggled with the process challenge of mixing UI design into the lifecycle. The traditional view has been that UI design is a requirements specification task and is undertaken during the requirements phase in a waterfall approach. Software engineering lifecycle processes were traditionally defined by practitioners with a background in mathematics or physics – UI design was an afterthought. Better attempts at mixing usability and UI design with the lifecycle have been published in recent years by practitioners with an arts and humanities background such as Deborah Mayhew’s “Usability Engineering Lifecycle” [Mayhew 1999]. Mayhew integrated usability engineering with Ivar Jacobson’s OOSE (Object-oriented software engineering) method. However, the pressure in recent years to deliver more value, more often through shorter development cycles with better focus and risk management has caused a switch to RAD or Agile software development methods. Once again, these newer software development methods have been created by practitioners with little experience or background in usability or interface design. This has led Larry Constantine [Constantine 2001 a & 2001b] to observe that Agile methods (notably Extreme Programming) are bad for usability. Peter Drucker taught the business world that value is perceived and defined only by the customer. The costs associated with creating a product are irrelevant. The price that can be achieved is defined by the value perceived by the customer. Michael Porter refined this model to show that value is defined by the consumer at the end of a value chain. Equally, it could be said that there is no value if the end user cannot use a feature in a software product. Value is perceived through usage. Without usability there is no value. The first of the 12 principles of the Manifesto for Agile Software Development [Cunningham 2001] states that “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” It can, therefore, be deduced that user interface design and usability are critical to the success of Agile software development. In his work on the Theory of Constraints (TOC), Eli Goldratt defined the rate of value delivered from a business as Throughput [Goldratt 1984]. He went on to define the goal of the business as the maximization of Net Profit and Return on Investment (ROI). Net Profit is defined as Throughput less operating expenses. ROI is defined as Net Profit divided by the capital invested in the business and its stock of raw material or inventory. TOC is directly compatible with the first principle of the Agile Manifesto. In 1997, Goldratt published his TOC solution for project management – Critical Chain (CCPM) [Goldratt 1997]. In recent months, there has been increased interest in the use of CCPM with software development [Newbold 2003; Zultner 2003; Brandt 2003]. In Copyright David J. Anderson 2004 2
    • Scheduling UI Design with Critical Chain Project Management Revision 1.5 October 22nd 2004 [Anderson 2003a], I show how to use the CCPM single project solution with Agile software development methods such as Feature Driven Development. CCPM is compatible with some Agile methods and can be used to facilitate the “early and continuous delivery” aspect of the first principle of the Agile Manifesto. Critical Chain also offers a solution for multi-project program management organizations [Patrick 1998, Leach 2000, Chapter 7]. The multi-project solution uses a shared resource to regulate the flow of work throughout the whole organization, whilst maximizing Throughput. This article will show you how to establish the UI Design group as the system constraint (CCR) and to use it as the synchronizer for program management of a multi- project Agile software development organization. Critical Chain regulates the flow of value in the system. However, without user interface design and usability, there would be less value realized. Hence, to maximize the goal of the organization both must be included in the lifecycle process for a competitive software engineering organization. Mapping Value Before commencing to build a product, it is first necessary to understand what represents value for the end consumer. Alan Cooper calls this process“conceptual design” [Cooper 1999, page 23]. In order to map the value offered by a conceptual design, a detailed list of features offered by the new software must be created. Each feature represents a nugget of value. These can be used to track the flow of value through the system. Lean Design Approach The Japanese have shown that they are better at designing cars than their American or European competitors. They can design a car and bring it to market faster using fewer resources. Womack et al, report that during the 1980s a typical new model took 46 months to bring to market as opposed to 60 months for American competitors [Womack 1991, page 111]. Mary and Tom Poppendieck introduced the notion that the principles of Lean Design are compatible with the Agile software movement [Poppendieck 2003a]. As they explain, the essence of Lean Design is a breadth first, coarse-grain of detail approach which delays commitment until the last responsible moment. Such techniques exist for UI design and are commonly referred to as “interaction design” [Cooper 1999, page 23] or “user interface modeling” [Anderson 1999]. Interaction Modeling Techniques 4thpass Inc., a subsidiary of Motorola based in Seattle, Washington uses Visual Vocabulary (VV) diagrams [Garrett 2000, 2002], as shown in Figure 1, to build a breadth first, low detail model of its Mobile Application Server software – a telecommunications grade application designed for use with packet-switched mobile data networks. Copyright David J. Anderson 2004 3
    • Scheduling UI Design with Critical Chain Project Management Revision 1.5 October 22nd 2004 Figure 1 – VV Model for MAS Content Browser The VV notation is designed for use with the Web and is only truly suited to software which will be deployed in a web browser. However, an alternative is available for traditional GUI applications – Statecharts – already adopted as part of the UML. Ian Horrocks documented how to how to use Statecharts for UI design in his book on the topic [Horrocks 1999]. Since then, I [Anderson 2000, 2001] with Brían O’Byrne [Anderson 2003b] have shown how to extend the notation to fully model the elements of interaction design. Figure 2 shows a Statechart representation of the VV diagram from Figure 1. Figure 2 – Statechart Model for MAS Content Browser Copyright David J. Anderson 2004 4
    • Scheduling UI Design with Critical Chain Project Management Revision 1.5 October 22nd 2004 Statecharts offer the designer interesting opportunities. It is possible to continue with the Statechart design, defining ever more detail within the hierarchy of states. Hence, Statecharts really do resemble the design techniques of coarse-grained initial framework with precise detail added later that is used in Lean car design [Poppendieck 2003b]. When final details are known the mold is updated and the fine detail is cut into it. The same technique can be achieved with Statecharts. This is not true of Visual Vocabulary models which rely on auxiliary notes and a UI specification or detailed design document for this purpose. Listing Client-Valued Deliverables The VV model provides a map from which a list of UI design deliverables for the project can be drawn up. From the model, a full list of each container, view, dialog, tab pane, wizard or alert box can be readily compiled. This list represents the client-valued functionality to be delivered. For each item on the list the UI Design team will need to create a detailed design and specification and hand it off to the UI developers for coding. In turn, the UI developers can also use the VV model (or Statechart) to devise a list of view and controller classes which must be written to facilitate the application flow. Feature Driven Development (FDD) FDD is described as a simple 5-step lean software development method [Palmer 2002]. The 5steps are: Modeling, Feature List Definition, Planning, Design, and Build (coding). Features are defined with a defined template and provide a very fine-grained definition of client-valued functionality. In the planning step, Features are grouped into Feature Sets which are in-turn grouped into Subject Areas. Feature Sets for UI design and development are based on containers with the UI model [Anderson 2003a] such as tab panes or procedural task flows such as wizards as a single deliverable. These will be made up of smaller fine-grained items of client value such as pages, views, tables, list boxes, etc. Critical Chain Planning Critical Chain is a new paradigm of project management which accepts that project work is probabilistic rather than deterministic. Critical Chain defines the constraint for a project as the delivery date. If the delivery date is the inviolate constraint then all other decisions on the project must be subordinated to the decision to hit the delivery date. Critical Chain asks us to build in time buffers, known as the Project Buffer and the Feeding Buffers to absorb uncertainty. The Project Buffer protects the delivery date from uncertainty. Knowing how big to make the buffers and where to place the feeding buffers requires an understanding of how the value generating work flows through the system and the dependencies between those value generating deliverables. Capacity Planning Each item on the Feature List can be weighted for complexity and risk and the weightings used to estimate the effort involved in completing the work. At 4thpass average effort metrics have been gathered for both UI design and development Copyright David J. Anderson 2004 5
    • Scheduling UI Design with Critical Chain Project Management Revision 1.5 October 22nd 2004 deliverables1. These are used to calculate an unprotected level of effort estimate for a whole project. For CCPM purposes, each Feature Set is considered as an individual deliverable. The Content Browser shown in Figure 1 would be considered a Feature Set. Tracking the Flow of Value The flow of value through the system of software production (including UI design) can be monitored by tracking the progress of each Feature. Regulating the Flow The drumbeat [Goldratt 1984] or takt time [Womack 1996] of the system will be set by the ability of the system’s capacity constrained resource (CCR) to consume the Features being tracked. Management should decide which element of the system should be designated as the CCR. They should then insure that all the other parts of the system have sufficient investment and resources so that they are never fully loaded. The flow through the system is then regulated by the capacity of the CCR and all the other functions will experience some slack time or under-utilization. As Tom DeMarco has pointed out [DeMarco 2001] some slack in the system of software development is a good thing for everyone concerned. The flow of value through the system is then regulated by the production rate of detailed UI design specifications. Single Project Solution CCPM requires a PERT chart to be created showing the dependencies between the Feature Sets. In turn UI Feature Sets will have dependencies on back-end code or business logic. The Content Browser from Figure 1 would require business logic and persistent storage for a content catalog before it would be able to fully function. Figure 3 shows a CCPM PERT chart for a small development project. Business Business Application Logic 1 Logic 2 UI 1 Business Application System Product Integration Logic 3 UI 2 Interface 1 Test Figure 3 – Critical Chain PERT Chart for a Software Project This initial PERT chart has no buffers to protect the delivery date. In order to protect the delivery date a project buffer must be introduced. The size of the project buffer is based on the unprotected level of effort estimate for the Critical Path – in the case of Figure 3 that would be Business Logic 3 through Product Test. The size of the feeding buffer is based on the level of effort estimate for the feeding chain of Business 1 An average UI design spec for a single view takes 10 man hours to design and review. An average view class takes 8 man hours to design, develop and review. An average controller class takes 4 man hours to design develop and review. Copyright David J. Anderson 2004 6
    • Scheduling UI Design with Critical Chain Project Management Revision 1.5 October 22nd 2004 Logic 1 through Application UI 1. Figure 4 shows a revised PERT chart with buffers introduced. Business Business Application Feeding Logic 1 Logic 2 UI 1 Buffer Business Application System Product Project Integration Logic 3 UI 2 Interface 1 Test Buffer Figure 4 – Protected Critical Chain PERT Chart for a Software Project This plan is much better as the delivery date is now protected by buffers which will absorb variance during the development cycle. However, the plan does not yet include the UI design activity. It is important to add UI design activity to the plan because application UI coding is dependent upon it and the UI Design group is the system CCR. Hence, the plan has to be revised to add the UI design activity and to buffer it appropriately. If UI design is not buffered to protect it from uncertainty then UI design resources may not be available when they are needed and any delay will eat away at the Project Buffer. Figure 5 shows the completed plan with the UI Design resource scheduled into the project. Note the impact of analyzing the resource conflicts caused a re-ordering in the activities on the Critical Path. Figure 5 – Final Critical Chain Project Plan with UI Design as CCR Multi-Project (Program Management) Solution Critical Chain offers a solution for multi-project environments where some resources are shared across each of the concurrent projects in the system. This requires that the system constraint is selected from amongst the shared resources. The CCR is then used as the synchronizer (or drumbeat) for program. When the UI Design group is chosen as the CCR, the flow of UI design work – development of detailed specifications – can then be used to synchronize all work activities. All other functions including software Copyright David J. Anderson 2004 7
    • Scheduling UI Design with Critical Chain Project Management Revision 1.5 October 22nd 2004 development and quality assurance will incur slack time because by definition they are never entirely loaded. The work of the UI Design group, as the system synchronizer, will now need to be prioritized based on the order of precedence of the projects under way. Each project must be prioritized. This could be done based on Throughput value, or delivery date, or strategic value to the business, potential market share gains, or defensive posturing against an aggressive competitor. Regardless of the method used, the business owners must agree to prioritize the projects in development. The release of work for each project is now staggered based on the capacity and availability of the synchronizing resources – the UI designers. When there is a conflict, the higher priority project takes precedence and the lower priority one is re-scheduled. In order to insure that UI Design resources are always available when promised, a capacity buffer is introduced whenever a UI Design resource is switched from one project to another. The capacity buffer is designed to absorb uncertainty and insure that the UI designer is always available to start on the next project by the promised date. Scheduling UI Design as the Drum The UI Design manager needs the UI design effort estimates from the interaction design and the project prioritization in order to schedule the UI resources. The CCPM plans for each project provide an indication of the earliest time the UI resources are required and the duration they will be needed. The UI resources must be scheduled in order to best facilitate the desired project delivery dates whilst not exceeding the buffered capacity of the UI Design team. Figure 6 shows a revised plan for a two project multi- project organization using UI Design as the synchronizing system CCR. Business Business Application Feeding Logic 1 Logic 2 UI 1 Buffer UI Designer UI Designer Buf Business Application System Product Project Integration Logic 3 UI 2 Interface 1 Test Buffer Cap Buf Business Business Application Feeding Logic 1 Logic 2 UI 1 Buffer UI Designer UI Designer Buf Business Application System Product Project Integration Logic 3 UI 2 Interface 1 Test Buffer Start Project 1 Start Project 2 End Project 1 End Project 2 Figure 6 – A Multi-Project Plan with UI Design as CCR showing Capacity Buffer Copyright David J. Anderson 2004 8
    • Scheduling UI Design with Critical Chain Project Management Revision 1.5 October 22nd 2004 Implications of CCPM on the Organization Sizing Buffers All buffers in a CCPM plan should be sized based on the uncertainty associated with the aggregate client-valued deliverables in any given chain or synchronizer task. Aggregating small tasks reduces uncertainty by the square root of the sum of the squares (SRSS) [Reinertsen 1997, page 211]. For example, let’s assume that a task might take 12 days on average based on empirical data. When asked to estimate it, with 80% confidence a developer might state that it will take 20 days. This represents an 8 day safety margin over the 12 day norm. If three similar tasks were undertaken then we might expect a total safety margin (or buffer) to be 24 days. However, if we calculate the SRSS for the same tasks as shown in Figure 7 then the real safety margin required is only 14 days. 13.856 = (8) 2 + (8) 2 + (8) 2 Figure 7 – SRSS for 3 tasks each with an 8 day safety margin The size of a buffer for an individual task should be based on the uncertainty associated with it. In software development and UI design this has a lot to do with familiarity with the problem domain and the type of solution available. Table 8 shows a rule of thumb for calculating a buffer based on the uncertainty associated with a task or deliverable. Uncertainty Buffer Size 0% 15% 10% 25%-30% 20% 50% 30-50% 100% >50% 200% Table 8 – Rule of Thumb for Buffer Size against Certainty Buffers are not Delays The intent of buffers in CCPM is not to delay projects but to protect the project constraint – the delivery date – or the overall system constraint (CCR) the Throughput capacity of the UI Design group – from uncertainty. In the event that less variance is experienced than was planned for, then the whole of a buffer will be unused. In the case of a CCR capacity buffer, this will allow the next project to start earlier. In the case of a project buffer, it will allow the project to be completed earlier. In the case of a feeding buffer, it will permit resources from the feeding chain to free up for use elsewhere within the organization on the same or a different project. Copyright David J. Anderson 2004 9
    • Scheduling UI Design with Critical Chain Project Management Revision 1.5 October 22nd 2004 Choice of CCR The UI Design group represents a good choice of overall system CCR for several reasons. The UI specification work is relatively predictable after the initial interaction design (VV or Statechart Model) is complete. The predictability is even greater when the UI designer employs a pattern catalog of commonly re-used concepts. Hence, there is a low variance and relatively low uncertainty associated with the development of the detailed UI specifications for each view. Larry Leach also suggests that the CCR should be strategic to the business and a provider of product differentiation, as well as being relatively close to the front of the process [Leach 2000, page 189]. UI design meets both of these criteria. It is definitely possible to differentiate a product line through usability and the UI design must also happen early in the process, if software development is to be expedited in an agile fashion. The caveat to this is a UI Design group will represent a bad choice of CCR if not tightly managed within a framework such as that described here. UI design must have criteria for work completion and a focus on Throughput. A poorly disciplined UI team would represent a very bad choice of CCR. Implications of Fully Exploiting UI Design as the CCR By definition the CCR in a multi-project CCPM solution must be fully exploited. This means that it will be fully loaded to its capacity with the exception of the capacity buffer. Hence, the UI designers will be the busiest and most focused professionals in the organization. Whilst others will experience slack time which may facilitate undertaking of tools development, bench projects, self-learning or formal training, the UI design team, on the other hand, will be fully loaded. It may therefore be necessary to supplement the UI Design team, from time to time, with temporary contract workers, so that permanent staff can be rotated off for training and professional growth. Copyright David J. Anderson 2004 10
    • Scheduling UI Design with Critical Chain Project Management Revision 1.5 October 22nd 2004 Acknowledgements Figure 1 is copyright 4thpass Incorporated, all rights reserved, used by kind permission. References [Anderson 1999] Anderson, David J., User Interface Modeling,, March 1999 [Anderson 2000] Anderson, David J., Extending UML for UI,, September 2000 [Anderson 2001] Anderson, David J., Extending FDD for UI – implementing Feature Driven Development on Presentation Layer Projects,, February 2001 [Anderson 2003a] Anderson, David J., Agile Management for Software Engineering – applying the Theory of Constraints for Business Results, Prentice Hall Professional Technical Reference, 2003 [Anderson 2003b] Anderson David J. and O’Byrne, Brían, Lean Interaction Design and Implementation: Using Statecharts with Feature Driven Development, Proceeding of ForUse 2003 [Brandt 2003] Brandt, Douglas R., A New Vision For Project Management, The Cutter IT Journal, 2003 [Constantine 2001a] Constantine, Larry L., Process Agility and Software Usability: Toward a Lightweight Usage Centered Design, Proceedings of OOPSLA, 2001 [Constantine 2001b] Constantine, Larry L., Methodological Agility, Software Development Magazine, June 2001 [Cooper 1999] Cooper, Alan, The Inmates are Running the Asylum – why High Tech Products Drive Us Crazy and How to Restore the Sanity, SAMS Publishing, 1999 [Cunningham 2001] Beck, Kent, Beedle, Mike, van Bennekum, Arie, Cockburn, Alistair, Cunningham, Ward, Fowler, Martin, Grenning, James, Highsmith, Jim, Hunt, Andrew, Jeffries, Ron, Kern, Jon, Marick, Brian, Martin, Robert C., Mellor, Steve, Schwaber, Ken, Sutherland, Jeff, Thomas, Dave, Manifesto for Agile Software Development, 2001 [DeMarco 2001] DeMarco, Tom, Slack – Getting Past Burnout, Busywork, and the Myth of Total Efficiency, Broadway Books, 2001 [Garrett 2000] Garrett, Jesse James, A Visual Vocabulary for Describing Information Architecture and Information Design, [Garrett 2002] Garrett, Jesse James, The Elements of User Experience: User Centered Design for the Web, New Riders, 2002 [Goldratt 1984] Goldratt, Eliyahu M., The Goal, The North River Press, 1984 [Goldratt 1997] Goldratt, Eliyahu M., Critical Chain, The North River Press, 1997 [Leach 2000] Leach, Lawrence P., Critical Chain Project Management, Artech House, 2000 [Newbold 2003] Newbold, Robert C., Bridging the Reality Gap, The Cutter IT Journal, March 2003 [Mayhew 1999] Mayhew, Deborah J., The Usability Engineering Lifecycle, Morgan Kaufmann, 1999 [Palmer 2002] Palmer, Stephen R., Felsing, John M., A Practical Guide to Feature Driven Development, Prentice Hall, 2002 [Patrick 1998] Patrick, Francis S., Program Management – Turning Many Projects into Few Priorities with TOC, Focused Performance, 1998 [Poppendieck 2003a] Poppendieck, Mary and Poppendieck, Tom, Lean Software Development: An Agile Toolkit, Addison Wesley, 2003 [Poppendieck 2003b] Poppendieck, Mary, Morphing the Mold, Software Development Magazine, July 2003 [Reinertsen 1997] Reinertsen, Donald G., Managing the Design Factory – A Product Developer’s Toolkit, Free Press, 1997 [Womack 1991] Womack, James P., Jones, Daniel T., and Roos, Daniel, The Machine that Changed the World, Harper Collins Publishers, 1991 [Womack 1996] Womack, James P., Jones, Daniel T., Lean Thinking – Banish Waste and Create Wealth in your Corporation, Simon & Schuster, 1996 [Zultner 2003] Zultner, Richard E., Getting Projects Out of Your System: A Critical Chain Primer, The Cutter IT Journal, March 2003 Copyright David J. Anderson 2004 11