WBS.com(ponents)--building a better WBS for object technology
Are you tired of all the “.com” things that are showing up on the market today? How are companies able to create a new “.com” every other day. What is making it so easy for these companies to get started? Or is it so easy? The answer to these questions has something to do with the ease and reusability of the underlying software development languages and approaches that companies are using today. Some of the more successful software development languages used today are Java and C++. One of the main selling features of these new languages is that they enable the developers to create objects and components that can be used as building blocks for all software and hardware development. How might some of these companies go about planning their projects using this technology to get their product to market faster? This paper presents one of many possible approaches to this question. The approach that is shared with you below has been used by telecommuncation companies, financial institutions, aerospace industry, software development consulting firms and many other organizations. Those that have used it are some of the leading organizations with regard to innovative technology. This proven approach may help you to get your projects moving using Internet technology a little faster then you may have previously thought possible.
Getting Started With a Project Charter and Scope
The success of any project must be viewed from the perspective of the customer and is based on a thorough understanding and agreement on what the customer wants. To obtain this understanding, there are three key components in early planning that can make a project a success. These components are developing a good project charter, developing and agreeing to project scope, and creating a work breakdown structure. When creating these documents it is important to follow these axioms: Simplicity is strength, standardization provides flexibility, and consistency equals success (Block 1999, p. 44).
Simplicity is needed to understand the customer's need for the project at a high level. A common error to avoid is the temptation to analyze and problem-solve before the needs are fully understood. Standardization allows a project manager more time to focus on the important issues. Consistency provides project success through providing a means to measure and communicate project information in a commonly understood format. These three axioms should be applied to the creation of a project charter and all the documents created in the planning process.
What to Include in a Project Charter
A charter is built on the basis of a business vision and can have a variety of forms. The size of a project charter depends significantly on the size of a project or the project work effort. The following exhibit provides the building blocks of the items included in an effective project charters.
The project charter is created based upon the business vision or the business need. A project charter is best when written by the project sponsor(s), ensuring project ownership.
• The project purpose statement is derived from the business need. It documents a conceptual understanding of what the project is about and how it is to be accomplished. Because of the importance of the project purpose statement it is elaborated upon further in the next section.
• Goals and Objectives are derived from the project purpose statement. They are a further clarification of the purpose statement. Goals are usually a more broad or general statement about what the project is to attain. Objectives are usually Specific, Measurable, Attainable, Reasonable, Timely (SMART).
• Cost Benefit Analysis or a budget overview is included in the charter to clarify the financial information associated with the project. The associated costs are only estimated at this time. Cost will be further defined in a planning phase of project management.
• The customer, the project manager and other stakeholders define assumptions, constraints and critical success criteria.
• Product Characteristics are general descriptions about the product or service the project has to produce.
• Stakeholders are persons who have an interest in or can influence the outcome of the project, and may come from other organizations. Management review and control boards provide governance and control over the project and may sponsor it.
The Value of a Purpose Statement in the Project Charter
The purpose statement is the most important component of the project charter. It is the foundation that defines the purpose of the project and how the completion will be assured. The reason this particular component of a charter is so useful is because it eventually translates into the high-level components or deliverables to be created by the project.
Two Examples of Purposes Statements
1. The purpose of this project is to provide consumers the ability to pay for gasoline at the gas pump.
• By providing a mechanism by which they can pay by cash or credit
2. The purpose of this project is to provide better services and information to employees using Internet technology
• By providing a new payroll system that will allow for web-based access to employee information in a secure environment
• By allowing employees to enter their hourly or timecard information
• By providing easy access to all employee information for their individual information such as retirement data and access to summary of benefit or deduction
• By providing an employee the capability to modify their information immediately if a significant event occurs such as change of address or marital status
The following exhibit provides the guidelines for creating a project purpose statement. At this stage the project is being defined in its simplest form. Therefore, there should never be more than seven “by” clauses associated with the purpose. If you use more than seven “by” clauses you are beginning to over analyze the simple purpose of the project. Keep in mind you will be creating a scope document and a WBS later in the project that will elaborate on these details.
With regard to the purpose statement and the WBS, at this early planning stage keep a watch on the nouns that are used in the purpose statement. You will see them again as we discuss objects and the WBS.
Guideline for Defining Project Scope
Project scope consists of three components: Scope Statement, Scope Definition and the Scope Management Plan. All three documents are significant, however this paper only discusses the scope statement and scope definition because of their impact to the entire project definition. The scope management plan guides the management of the scope and how changes will be integrated back into the first two scope planning documents.
Scope Statement and the Statement of Work
Information Technology (IT) organizations either issue statements of work to obtain some level of consulting services, or they are the consulting organization and are the receiver of a statement of work. This document must be clearly understood by both parties. The rapid market place for software products does not always allow an organization to elaborate on a statement of work like they had been able to in the past. The solution to this problem is to use the content of the project charter or other initial project documents as a guide to outline the high-level deliverables of the project in the statement of work (SOW). The SOW would then be used as the contractual driver for the project. (Note: This approach assumes a time and materials project.) It would then be up to the project management team, which includes the project sponsor; to use a scope statement and WBS as the “living breathing” documents, which would capture the changes to the scope that occurs over the course of a project.
The scope statement is used to make future project decisions. The scope statement is modified as you learn more about the project scope during the progression through the project planning activities. The following items should be added to the scope statement document in addition to those items found in the project charter:
1. High-level deliverables
2. List of other projects or business units impacted by the project
Deliverables are defined in terms of something that is measurable, tangible, verifiable outcome, result or any item that must be produced to complete a project or part of a project (PMBOK® Guide 1996 p. 162). Therefore, deliverables are usually nouns. High-level deliverables are those items that can be derived from the project purpose statement found in the project charter. In the example given earlier you can derive the following deliverables:
• Payroll System to include
• Internet web site (Internal to the company employees) and secure
• Employee Information
• Retirement Data
Once you have a clearly defined scope statement the next step is to further refine the high-level deliverables through scope definition or WBS.
Scope Definition for Today's Information Technology Projects
Scope definition incorporates the content of the project charter and scope statement, and begins to decompose the high-level deliverables into subdeliverables and the associated activities and tasks. Work effort will be assigned to the WBS and will incorporate task dependencies and the types of skills needed to complete the work.
The WBS is a hierarchical decomposition of the total work effort, including all labor, material and other direct project costs. A WBS is project-oriented based on the high-level deliverables associated with meeting the business needs.
The WBS provides the framework for all cost budgeting, planning and reporting activities on a project. All WBS deliverables are mutually exclusive in that all the work associated with a given WBS deliverable appears with that deliverable and only that deliverable. This also applies to object technology in that the real world things that you are building are mutually exclusive. The items that are built should do one thing well. There is a direct correlation between these real world things or deliverables you are building and your work breakdown structure, but before we explain this correlation, you must first understand what is object technology and what are some of the tools and techniques used in Object-Oriented Development.
The object-oriented (OO) paradigm that is used in software product development methodologies focuses on the real-world items and concepts that are part of the problem domain. In other words, it maps very nicely to the customer's problems and they can relate very easily to the real-world “things” that are being built in each increment. OO development primarily focuses on the structure and characteristics of the objects in the problem domain, instead of on how they are used. Because an object's characteristics are more stable than the uses of the object (i.e., behaviors or processes change, but the “things” in the problem don't necessarily go away), OO development is more resilient to change than a structured analysis and design approach or functional decomposition. OO development is particularly well suited to highly user interactive activities.
What is OO Technology?
Organizations that are implementing Internet solutions and all those “.com” or Internet applications should be using component or object technology. In addition, today's software projects are also making use of object-modeling techniques (example UML Unified Modeling Language). In the payroll example, employee and paycheck are both examples of objects or classes in this system.
A “thing” is a noun. Since, an object relates to the real world “things” they also nouns. For example, in the payroll example a paycheck is a thing that the business sponsor would like to have created in order to accomplish the goal of a payroll system. Objects have structure, which means they have attributes and behaviors that are associated with these real-world things. Each object in a system is unique, such as my paycheck is different from your paycheck. However, objects can be classified or referred to as a class. You will often see objects and classes used interchangeable. Classes can also be group into related items for implementation. This grouping of classes are sometimes called components or packages. A component can not only consist of software but can also include hardware installation as well. A package is software related only. Packaging is used to group like things of a system together. For example, in the payroll application you could group all classes or objects related to taxes together. When building an object-oriented system remember that an object should do one thing well.
With an Object-Oriented project, you should be thinking about the things in your system instead of the traditional way of implementing a system by what “processes” are to be performed. What is different about object technology and the traditional software development is that you can use these “things” or nouns in your Work Breakdown structure as a means of assigning work.
Work Breakdown Structure for Component or Object Technology
Let's say for example, we wanted to create a company called www.payroll.com. After creating our project management documents (Charter and scope) we might begin to think about what are the “things” that are part of a payroll systems. Examples of the real world items are found in Exhibit 3.
In object technology you want to create a domain model that correlates to these real world items. In your WBS you would also begin to use these nouns as the types of components you are going to build for this application. An example of a domain model and a possible WBS for this application are found in Exhibits 4 and 5.
The business deliverables directly translate into objects associated with particular software development activities. For example, in Exhibit 5, you can see that the WBS contains subsystems that are associated with that business or real world items (nouns) found in a payroll system. IT managers should create the WBS to correlate directly with the domain objects or components to be developed.
Activities in the WBS
Does the WBS include activities or should it? (Berg, Colenso, pp. 69). The WBS should be structured from a process or life cycle basis (i.e., phases). This is to provide the manage with the flexibility in approach as well as to recognize that many of the major components in life cycle structures are also major deliverables. This also aids in the understanding of product breakdown structures. In object-technology, the method of implementing the product is different than traditional means of software development. The method often used to implement this type of software project is an incremental and interactive approach. This approach involves packaging or grouping activities to accomplish a set of functionality. Each package may be worked on in parallel to accomplish the project goal faster. We will discuss this approach in the next section.
The approach of packaging is accomplished through grouping use cases. A use case can be thought of as the activities that are needed to accomplish the high level deliverable. A use case describes from a business perspective the functionality that will be provided to the business sponsor. In the payroll example, you might have a use case to “Add Employee”or “Maintain Employee Information.” The deliverable from the use case activity is the document that describes how this activity is going to be accomplished. Therefore, use cases or activities should be included in an object-oriented work breakdown structure. Including these use cases will facility in the grouping or packaging of functionality so that it can be delivered incrementally to the business sponsor.
In object technology we will not only have the nouns (objects or classes) and activities (use cases) in our work breakdown structure but we must also think about the process we are going to use to implement each of these components. A product or process approach must be applied to each of these high-level deliverables.
Incremental and Iterative Project Life Cycle Approach
Project Management Plan
As part of the overall project plan, especially technology projects, it is always a good idea to create a project management plan. The project management plan is a comprehensive set of management documents. The project management plan contains three sections. The first section should provide the project sponsor with an overview of the project (i.e., project charter and scope), it should also include and overview of the development approach in terms of the development life cycle and the development methodology. The second section should describe all project controls and support processes. The third section should describe the phase specific development and support processes, if necessary. With object technology and Internet the development is a little different than the traditional waterfall life cycle for product development.
Most of today's IT projects are done using an incremental approach. Gone are the days when the requirements document is thrown over the fence to the developers and no further changes could be made. The incremental approach builds upon proven capabilities while providing constant feedback with the customers to continue to elaborate and refine an increment. Before discussing how the actual increments are build, an outline of a typical software development approach is provided to understand how an increment is implemented. Exhibit 6 shows a typical project processes for a software engineering development project. In the center of the exhibit you will see some typical phases used in software development. These phases are repeated depending on the increment you are developing.
Development Life Cycle
Today's projects are developed using a rapid application development approach. This development life cycle uses incremental builds and deliveries to reduce risk and gain early feedback for increased stakeholder (e.g., customer, users) satisfaction. The model is based on planning and development of incremental builds, providing sets of consistent functionality in each increment to the verification environment for ongoing product integration. Early development of testable functionality reduces technical risk by allowing more customer feedback. Technical risk or requirements changes are minimized because of each increment's short development cycle time. These increments are also referred to as packages. This is not a work package. If the payroll system was done using object technology the package would consist of a set of certain functionality associated with, for example an employee or paycheck.
All phase specific processes are executed and performed in the standard order for each increment. The need for parallelism and the short development time of each increment forces some changes to the full project timing of phase starts and stops and the formality of reviews. The timing of the controlling processes, size of the increments, the need for stakeholder involvement and the need for rapid design decisions fit neatly into how project teams are organized.
Exhibit 7 shows a high-level incremental rapid implementation model. The model shows the flow of control of processes that must be executed within each activity. The top of the exhibit shows the planning and requirements activities, providing technical management and planning of each increment. The planning and requirements activities execute the processed that drive the technical analysis of the project, starting with mission analysis at the start of a project, and then defining and allocating requirements, making the determination of requirement that will be developed in each increment. This activity prioritized the order of requirement development and incremental builds based on many factors, including early risk mitigation, the need for customer feedback and testability.
The planning of all increments is maintained in the WBS and master plans. The package development depicted in the exhibit shows how package production is domain based, and packages are produced sequentially, with internally tested packages being dropped into the verification environment before the start of each new package environment. There can be any number of packages in an increment, from 1 to n, depending on the size of the project and the need date for each piece of functionality. The process flows within each package development usually follows the waterfall life cycle model or spiral model.
Continuous integration and tests activities are maintained through a test environment. This environment is capable of accepting increments, and immediately performing system level integration testing. The tested system grows with each incremental build. Incremental builds can consist of software and hardware or any combination of products that are integrated into a testable piece of system functionality. The tests are scenario or use cases that were written in the requirements phases. The use cases are verified, as needed to formally prove the requirements. There can be various levels of testing, depending on the integration needs of the system. Depending on the nature of the project, incremental builds may remain under configuration management control baseline for one or more combined deliverables. This process could also be called an incremental/iterative approach. These iterative increments are often called releases. This incremental iterative approach to life cycle development will provide greater risk containment and customer satisfaction and confidence than the traditional waterfall approach.
In order to accomplish all this complex coordination of packages and implementation of increments, a good sold development and implementation team is required.
Defining a Winning Team
The project teams should be small in size. Each team is associated with a increment or package that is to be build using object technology. An example of the kinds of team members you should have available to not only the overall project but then to each increment can be found in Exhibit 8.
Team structures are very important in object technology. Keeping the teams small and cohesive is very valuable to the installation of smaller more dynamic building of packages and objects. Good communication among the team members is very important. Team members will play a variety of different roles on the project. Team members should play different role, such as professional shoppers, jewel makers, storytellers and factory workers. A professional shopper would be a person looking for new tools or new ways of implement the product. This could also involve shopping for objects or classes that may already have been created as part of shareware or other applications. A jewel maker is someone who concentrates on a smaller component of the system and refines it until it is extremely efficient to the company, project team and ultimately the product development. A storyteller is someone who helps the project manager communicate among team members. A factory worker is someone who takes a heads down approach to developing and is only interested in getting the assigned task completed. This role is very important in concentrating on getting these smaller packages of functionality to the project sponsor quickly.
Project teams, project process and technology all play important roles in the implementation of an object-oriented project.
Object-Oriented projects are different. They are implemented much faster than traditional methods of software development. Objects allow the project manager to implement functionality and then build on that functionality as requirements are modified. By concentrating on the “things” or nouns in the system rather than the process it makes it easier to adapt to change. WBS can now associate directly to the real-world business items that the system is to deliver. The WBS can be packaged and installed in increments so that delivery to the customer can begin quickly. Smaller teams are important to accomplishing the goal of rapid implementation. Using Object Technology and a good WBS can make it easier to implement Internet technology. Perhaps you too can now create you own “.com” company.
Truhlar, P. Bernadette, & Clarke, Luis. (1999). Applying early planning techniques for project success in the ever-changing information technology industry, Nordnet99, September 1–7.
Lockheed Martin Project Management Process
Lockheed Martin Advanced Concept Center, Executive Overview of Object Technology
Block, Thomas R. (199, April). The seven secrets of a successful project office, PM Network, pp. 43–48.
PMI Standards Committee. (1996). A guide to the project management body of knowledge (PMBOK® guide), p. 48, p. 162.
Berg Cindy, & Colenso, Kim. (2000, April). Work breakdown structure practice standard project WBS vs. activities. PM Network, pp. 69–71
Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA