In order to be able to create a release plan, we need to have the following available:

• A prioritized and estimated product backlog
  We need to have some of the stories of the backlog prioritized and estimated. We can plan for all those stories only
• The estimated velocity of the Scrum team (how much work can be accomplished in each sprint)
  We need to have a good idea how much work the Scrum team can deliver during each sprint.
• What features constitutes a release (milestones)
  We need to know what set of features that will work as a release for the client. It won’t make any sense to deliver functionality that is dependent on functionality that is still sitting in backlog.

Now it’s just a matter of listing the product backlog in priority order and plan releases. It’s important to understand that the release plan is not a static plan, thus it will change on a regular basis as the backlog is amended or as the velocity of the Scrum team changes.

Here is my suggestion how to conduct the Daily Scrum meeting:

• The meeting is no longer than 15 minutes and is held every day during the Sprint.
• The meeting should be held the same time and same place each day.
• There are three questions to be answered by each team member:
  • What did I do since our last meeting?
  • What do I plan to work on until our next meeting?
  • What impediments do I have?
  • The meeting is self-organized, just like the team is, so no one is “running” the meeting.
  • I suggest that everyone stands up during the meeting and phones and electronics are turned off during the meeting.

The meeting is not held to solve problems. If problems come up during the meeting, postpone them to another meeting after the Daily Scrum. The idea is that everyone can get a good feeling what is being worked on and also see if any potential problems may arise from several team members working in the same area. If a team member encounters impediments the Scrum Master will work on the removal of the issues.

• It’s very time consuming to write an enterprise design document. The document has to be very elaborate and detailed in order to define the exact scope of the final product.
• When the client wants changes to the project scope, it’s a huge task to update the design document to reflect those changes.
• According to Standish Group, 64 percent of the features that a client requests are rarely or never used (http://blog.standishgroup.com/).

So we spend a lot of time building and documenting requirements and then the client ends up using 36% of all the features we developed. So the project ends up taking longer, costing more, and providing the client with a lot of features that are rarely or never used.

Sounds like a lot of waste, right? Wouldn’t it be a better if we only provided the client with the features they used all the time and not spend time documenting and planning for features that they never use? That’s why User Stories are an integral part of an agile project framework.

Requirements vs. User Stories

Here is an example of the Requirements for a product:

• The product shall have four wheels.
• The product shall have a gas engine.
• The product shall have a rubber tire mounted to each wheel.
• The product shall have steering wheel.
• The product shall have a steel body.

Can you guess what we are building from these requirements? A vehicle of some kind, right?

Here is an example of a User Story for a product:

• As a home owner I want to be able to mow my lawn quickly and comfortably so that I don’t have to work hard at it.

Can you guess what we are building from this story? This is much easier, right?

Let’s take a look what the real differences between requirements and User Stories are:

• Requirement documents are written in the solution domain, while Users Stories are written in the problem domain.
• Requirement documents are large, complex, and often hard to read. They must be maintained each time the project requirements change. User Stories are lightweight and will only be expanded upon at the point of implementation.
• Requirement documents try to answer all questions up front. User Stories are agile and put off decisions until the last practical moment.

The Scrum framework keeps a backlog of User Stories that are constantly prioritized and reprioritized, thus only the most important Users Stories are documented and developed into the final product. Ultimately the use of an agile framework and User Stories will result in that the client will only get and only pay for 36% of the features that they end up using and not get or pay for all the features they won’t be using.

How to make a User Story

A good User Story must have the following structure:

• As a <user>, I want to <function> so that I can <business value>

So a User Story is a small piece of business functionality and a placeholder for future conversations. It should also be detailed enough to estimate.

The User Story will typically be elaborated on once the story moves into the Sprint Backlog for execution. At this time the requirements are documented and a set of acceptance criteria are compiled. Acceptance criteria essentially explains how the functionality is verified and accepted as “Done”.

Six attributes of a good user story

There are six attributes that make a good user story. The following is a summary of an article written by Mike Cohn.

• Independent
  If possible we should make an effort to make the story independent on other stories. Potential issues can occur, for example, when a story with high priority depends on a story with low priority. If stories are dependent on each other, you should combine them as long as the resulting story doesn’t get too big.
• Negotiable
  A story is a short description of functionality and the details are to be negotiated between the development team and the client. We purposely don’t go into details when we write user stories because they are just reminders to have discussions what the requirements may be at the time the user story enters the execution phase (sprint). This doesn’t mean that we can add notes to the story as we write it if important details come up.
• Valuable to users and the purchaser
  A user story must provide a value to the users and/or the purchaser (the one that purchases the software). Most would think that a user story should be valuable to the user, but some stories will only have value to the purchaser. For instance a story could be “The software must run from the cloud, so that we don’t have to invest in and maintain hardware”. This story has no real value to the users, but certainly a value to the purchaser.
• Possible to estimate
  The story must be possible to estimate for the development team. If the story is too big or the developers don’t have the knowledge needed to fully understand the story, the story is not possible to estimate. In this case we need to split the story (if too big) or do research (called a Spike) to gain the knowledge needed to be able to estimate the story.
• Small
  If the story is too big it can be impossible to estimate. If we are building a website the story “A user can place buy an item from our website is an epic that is impossible to estimate. Buying something from a website involves a lot of different functionality with so many different tasks that we have to split the epic into smaller stories. The appropriate sixe of a story depends on the team, its capabilities, and the technology that’s being used.
• Testable
  A story must be written so that we are able to test it. We only know that a story is successfully developed if it passes a test. An untestable story usually comes up for non-functional requirements like “A user must find the software easy to use”. This story is impossible to test, thus should not be qualify as a story.

Benefits of User Stories

It’s pretty obvious that writing a user story is much less work than writing up detailed requirements, but if we eventually have to write the acceptance criteria and requirements for each User Story, where is the real benefit? To answer this question we need to look at how an Agile project is run. In an Agile project we place all the user stories in the Product Backlog. The stories are prioritized at the beginning of each Sprint, thus only the most important User Stories are scoped out and developed. Once the next Sprint starts, another batch of User Stories with the highest priority are scoped out and developed and so on. At the end of the project, we should end up implementing only the most important User Stories thus saving time and money on the User Stories that never made it into the project. Had we scoped out the requirements for these stories to begin with, it would all be for nothing.

So User Stories are very powerful and agile because they a simple to understand and easy to make and change. They allow changes to be made fast and by applying priority to all stories, we make sure only the most important ones are making it into the project. Essentially we end up developing close to the 36% of the requirements that the client actually will use as opposed to 100% of the requirements where 64% is not used. That saves time and money on the project.

Features used after delivery of a software project

Going through a major software project can be quite grueling, but once it’s completed, you hope your company gets the value of all the features and functions implemented during the project. The problem is that in most cases much of the functionality delivered as part of the project is never or rarely used.

A study by the Standish Group showed that 64% of application features and functions delivered in an average software project were never or rarely used. So, you just spent a lot of time and money on a lot of features, and almost two thirds are hardly ever used!

The problem lies in the way the project is planned and delivered. As you will see, the traditional project model requires a lot of up-front analysis and design. Users from different departments are asked for the requirements they would like to have as part of the project and typically ask for the maximum they can think of because they get to state their needs only once in the beginning of the project. Most of the time, many of these requirements are not really needed and end up rarely or never used in the final product.

In the following, I will go over the issues related to the traditional project model and how an agile approach delivers a leaner, less costly and overall better product for the end user.

Project management according to the PMI, the waterfall model

Let’s first discuss how a project traditionally has been (and in many instances still is) approached. The Project Management Institute (PMI) has published the Project Management Book of Knowledge (PMBOK) that in minute detail explains how a project is planned, executed, controlled, and delivered.

According to the PMI, a project is a series of process groups that ultimately ends up with a finished deliverable (product). Without going into too many details, the model the PMI uses to deliver a project is called the waterfall model. The waterfall model says that we have to follow certain steps in a specific order. The steps are usually as follows:

Result: Deliverable or Product.

In the waterfall model, we spend a lot of time up-front on analysis and design. On an average project, finishing the design and writing up the functional requirements in a design document could take several months. The design document is a detailed description of the entire scope of the project and is usually hard to read and understand; thus, very few stakeholders in the project actually read and fully understand it.

The waterfall model does not allow much flexibility to change directions and go back and rework things, hence, the term waterfall, indicating that once one step is done it can never be revisited. It’s not completely fair to say that the PMBOK does not allow previous steps to be revisited, but it’s usually not advisable to do it too much. If change happens in the waterfall model, it usually also means that the design document needs to be amended and approved once again, a time-consuming and cumbersome process.

There are three main issues with the waterfall model:

• The customer does not get the value of the project until the very end.
  No real value is delivered to the customer until the project ends. The customer can sometimes see bits and parts of the deliverable during the project, but the real value is not delivered until the end of the project.
• The model is based on a lot of planning and expects predictability.
  The PMBOK’s largest process group is the planning group. The PMI wants you to plan, plan, and plan. There is nothing wrong with planning, but if you lack experience in certain areas, it makes no sense to plan. The model really likes us to be able to predict everything in advance so we know how we will act in each instance. We also plan all the features that end up never or rarely being used.
• The model is not geared for change.
  Even though the PMBOK explains how to handle change, the PMBOK implicitly prefers few changes during a waterfall project. It also contradicts the concept of predictability: We don’t know what kind of changes we will encounter and consequently can’t plan how to react to them.

Project management according to Scrum

Scrum is an agile framework that allows the delivery teams and client to collaborate to build a quality product that ships early and often, while all the stakeholders are learning and relearning as they go. Sounds too good to be true, right?

Essentially, the agile approach involves slicing the traditional model into iterations. For each iteration, we perform analysis, design, development, testing, training, and deployment, but on a much smaller scale than in the traditional project approach. You can say that the agile model slices the traditional phases into smaller pieces and executes them in much more manageable iterations called sprints:

As you can see from the graphic, we cut the project up horizontally. We can potentially do a little bit of every phase in each sprint that typically runs for a few weeks.

Scrum uses user stories from the product backlog to determine what is executed in each sprint.

The user stories are simple overall business stories without all the details we typically specify when we do a traditional design. A story could say, “As a warehouse worker, I want to be able to pick my inventory using a scanner so that I can expedite the picking process and make fewer errors.” So, the story is written in the problem domain and not in the solution domain, making it much easier to understand and write than a traditional design write-up. For each sprint, the customer and project manager pick the five to seven most important stories, and they are the only ones executed for the sprint. In the next sprint, the next five to seven most important stories are picked and executed, etc.

Scrum resolves the three main issues with the waterfall model:

• Product is shipped early and often.
  The Scrum framework delivers value often by shipping a product increment regularly after each sprint (typically). The product includes the deliverables the development team has finished, and the customer can subsequently review and test the deliverable.
• Much less planning and much more doing and collaboration take place.
  Since we postpone the decision about which stories are executed until the very last moment, we analyze, design, and develop only the stories that bring the most value to the product and the client.
  Scrum values individuals and their interactions, and has ways for the team and the client to collaborate and align regularly to increase the transparency of the project.
• Change is expected and embraced.
  According to Scrum, responding to change is more important than following the plan. Clients always change their minds during the duration of a project, and Scrum embraces this change. All we need to do is write the change as a user story and place it in the product backlog. If the change has high enough priority, it will get executed sooner rather than later. If not, then the change wasn’t important enough to make it into the project in the first place.

The following is from the Scrum Alliance website (http://scrumalliance.org).

Scrum is an innovative approach to getting work done

Scrum is an agile framework for completing complex projects. Scrum originally was formalized for software development projects, but works well for any complex, innovative scope of work. The possibilities are endless. The Scrum framework is deceptively simple.

The Scrum Framework in 30 Seconds

• A product owner creates a prioritized wish list called a product backlog.
• During sprint planning, the team pulls a small chunk from the top of that wish list, a sprint backlog, and decides how to implement those pieces.
• The team has a certain amount of time, a sprint, to complete its work (usually two to four weeks) but meets each day to assess its progress (daily scrum).
• Along the way, the ScrumMaster keeps the team focused on its goal.
• At the end of the sprint, the work should be potentially shippable, as in ready to hand to a customer, put on a store shelf, or show to a stakeholder.
• The sprint ends with a sprint review and retrospective.
• As the next sprint begins, the team chooses another chunk of the product backlog and begins working again.

The cycle repeats until enough items in the product backlog have been completed, the budget is depleted, or a deadline arrives. Which milestone marks the end of the work is entirely specific to the project. No matter which impetus stops work, Scrum ensures that the most valuable work has been completed when the project ends.

Why is it called Scrum?

When Jeff Sutherland created the Scrum process in 1993, he borrowed the term “scrum” from an analogy put forth in a 1986 study by Takeuchi and Nonaka, published in the Harvard Business Review. In that study, Takeuchi and Nonaka compare high-performing, cross-functional teams to the scrum formation used by rugby teams.

Scrum is the leading agile development methodology, used by Fortune 500 companies around the world. The Scrum Alliance exists to transform the way we tackle complex projects, bringing the Scrum framework and agile principles beyond software development to the broader world of work.

Source: http://scrumalliance.org

The question most companies are asking themselves is: How much should I order to minimize my cost of carrying the inventory and minimizing the cost to order the inventory.

In order to make this determination Economic Order Quantity (EOQ) comes into place.

What is EOQ?

EOQ is essentially an accounting formula that determines the point at which the combination of order costs and inventory carrying cost are the least. The result is the most cost effective quantity to order.

When should you apply EOQ?

If you are having repetitive purchasing or planning on an item, you should consider applying EOQ. Some obvious examples using EOQ would be purchase-to-stock and make-to-stock. Repetitive buy maintenance, repair, and operating (MRP) inventory is also a good application for EOQ.

How is EOQ determined?

The basic EOQ formula is as follows:

SQRT(2 * (Annual usage in units) * (Order Cost) / (Annual Carrying cost per unit))

Where

• Annual Usage is the forecasted annual usage
• Order cost is determined be what is the cost to place the order. This includes the cost to enter the order, the cost to process the receipt, inspection, invoicing and paying the vendor. Some items may also have to be returned because of defects and that also adds to the order cost
• Annual Carrying Cost is the cost of having the inventory in the warehouse. That includes the interest the inventory is carrying by not having it as cash on hand. Insurance, taxes and storage costs also needs to be included

Example:

Annual Usage = 10,000

Cost per order = $2

Cost per unit (CU) = $8

Carrying cost percentage (percentage of CU)= 0.02

Carrying cost per unit = $8*0.02=$0.16

EOQ = SQRT (2*2*10,000 / 0.16) = 500

Sources:

Inventoryops.com http://www.inventoryops.com/economic_order_quantity.htm

Wikipedia: http://en.wikipedia.org/wiki/Economic_order_quantity

There are five process groups according to PMI. They are Initiating, Planning, Executing, Monitoring and Controlling, and Closing.

All groups contain a total of 44 project management processes of which 21 are located in the planning group. That doesn’t necessarily make this group the most important or most time consuming but it makes the group the most comprehensive group that covers all of the nine knowledge management areas (link).

In this article I will cover all the processes that goes into the planning group. I will not cover each process in detail but rather show the overall concept of the planning process group and what sequence the processes are executed in.

The order in which the planning processes are executed is determined by how the outputs of those planning processes are used. Most of the time the outputs are used as inputs in subsequent planning processes thus there is a natural order all the processes should be executed in.

Integration Management

1. Develop Project Management Plan

The project management plan is covered under the Integration Management knowledge area and essentially covers all the plans from all knowledge areas including baselines and risk registers (see link).

Scope Management

2. Scope Planning

The process of Scope Planning is about developing a plan that serves as your guidebook to the other scope processes. A common mistake is to plan the scope of the product here, but instead we plan how to conduct the scope gathering, definition, monitoring and control and verification for the entire project.

3. Scope Definition

Based on the preliminary project scope statement we will work to gain additional detail of the scope by doing analysis and design sessions. This process actually produces a detailed project scope and is used to create the WBS (see below).

4. Create Work Breakdown Structure

The Work Breakdown Structure (WBS) is a complete and very detailed decomposition of the entire scope in to small work packages that are easy to estimate for time, cost and activities (link).

Time Management

5. Activity Definition

Using the WBS we now decompose each work package into activities needed to complete each package.

6. Activity Sequencing

Once we have defined all the activities we need to put them into the correct sequence. We also need to make sure that activities that depend on other activities being finished are executed as soon as possible after the end of the previous activity. There are much more to this process and some is partially covered by my article about critical paths (Link).

7. Activity Resource Estimating

In this process we estimate how many resources (people and purchases) each activity requires. This is later used as an input into Cost Estimating.

8. Activity Duration Estimating

Here we estimate how long each activity will take.

9. Schedule Development

Here we use the outputs from all the previously planned processes and develop the project schedule. The project schedule is one of the most visible and important parts of the project plan and is often mistakenly referred to as the project plan. The schedule is part of the project plan but is not the project plan.

Cost Management

10. Cost Estimating

Each activity is analyzed to evaluate the time and resource estimates to establish a good cost estimate.

11. Cost Budgeting

The budget is also known as a cost baseline. The cost baseline takes the estimated cost and maps it back to the calendar to allow us to plan for cash flow and expenses.

Quality Management

12. Quality Planning

In this process we are planning how to make sure that the resulting product is of acceptable quality. See this article about quality management in IT projects.

Human Resource Management

13. Human Resource Planning

Here we plan how we will staff, manage, team-build, assess and improve the project team.

Communications Management

14. Communications Planning

This process is about how communication will be distributed and updated including the format of the communication. We also plan which stakeholders should receive the communication.

Risk Management

15. Risk Management Planning

I think you know get the idea about what we do in the planning processes. In this process we plan how we are going to handle risks in all risk processes.

16. Risk Identification

Here we identify the risks that we the project can encounter. Most think of risks as negative but some risks can also have a positive outcome. As project managers we tend to focus mostly on the negative risks since they can jeopardize the project outcome but some risks can have a good outcome. The output is a risk register that is an important part of the project management plan.

17. Qualitative Risk Analysis

In this process we prioritize the risks of the project and update the risk register.

18. Quantitative Risk Analysis

Here we will try to quantify the risk by assigning a projected value if the risk should occur. We want to know what the cost potentially could be to the project in case each risk would occur.

19. Risk Response Plan

Here we create a detailed plan what we will do if a risk should occur.

Purchase Management

20. Plan Purchases & Acquisitions

In this process we plan how we are going to purchase resources or products to the project. Since purchasing can happen during the entire project we may often come back to this process and plan accordingly.

21. Plan Contracting

Here we create requests for proposals and send them out to potential sellers.

In order to complete a successful implementation of a project we must be good at planning. Not all projects may need all the planning processes I mention above, but use this as a checklist for the project planning and include what applies to your project to ensure that you have planned the best you could before the project starts to execute.

So “who” and “what” determines what is considered quality? “Who” is an easy one. The customer has ultimately the final word what’s quality, not us. If they don’t perceive our products or services as quality they are not.

What’s Quality?

We need to determine what’s critical to the success of the business process and verify it with our customers. In order to do that we can use a tool called Critical-to-Quality (CTQ) tree. It is used to find out our customer’s requirements.

Steps to create a Critical-to-Quality tree

1. Identify the customer. We need to see if our customers need to be segmented due to different needs.

2. Identify the customer’s need. This becomes the first level of the tree.

3. Identify the requirements for the need. We usually want to identify at least 2-3 overall requirements. They become the second level of the tree.

4. Break down the requirements in the second level even further. We can brainstorm or ask our customers to provide feedback to determine this third level of requirements.

5. Validate the requirements with the customer. Since the customer has the final word on what’s considered quality, we need their validation of the requirements.

Let me illustrate how to build a CTQ tree. For this example we are reviewing a pizza delivery process.

1. Our customer can essentially be anyone that likes pizza. There is really no need for segmentation since they all have the same need: A pizza.

2. As determined in step 1, the customer needs a pizza to be delivered.

3. We can determine a few overall requirements: The quality of the pizza, the delivery speed and the variety of pizzas/toppings we offer

4. The quality of the pizza can be broken down to: How does it look? How does it taste? How warm is it when they get it?

5. Now we need to verify these requirements with our customers. We can do this in many different ways, like interviews, surveys, complaints etc.

The resulting tree in a graphical form is shown below.

Once we have determined what is Critical to Quality we can now work on improving the process so we can provide the best possible quality to our customers.

There are six processes in procurement management.

Plan Purchases and Acquisitions
Here we take a look at the project and determine which components and services of the project that we can handle internally and which ones we need to outsource. This is also called a Make-or-Buy Analysis. Hereafter the project manager needs to determine what kind of contracts we need to put in place.

There are several contract types that could come into play:

Plan Contracting
In this process we create detailed documents such as Requests for Proposals or RFPs. The RFP explains what is expected of the seller in terms of what should be done, when it should be done by, cost, time, and quality etc.

Request Seller Responses
This is the process where we distribute the RFPs and other procurement documents to potential sellers and have them respond to the RFP. We usually provide a deadline for all responses.

Sometimes we can also set up a bidder conference to allow sellers to ask questions. This is most often used of the requested services or goods are complex in nature and instead of answering the same questions several times in separate communications we can handle it all in one conference session.

We can also elect to advertise the bid to the public on websites or in newspapers. In some cases this could be a requirement by law, so make sure to check if this applies in each case.

Select Sellers
Now it is time to select the sellers from the received responses. The selection can be based on price, quality, delivery time etc. As the project manager it is up to you to determine which sellers are best for the project and select them accordingly.

Contract Administration
Here we review the contract and determine if the results match the contract. Were the goods and services delivered? Were they delivery on time? Were we invoiced the agreed amounts? Other contractual obligations can also be considered here.

Contract Closing
Here we are handling completing the contracts and terminating them officially. Hopefully the seller delivered according to the contract and we paid according to the contract, but contracts can unfortunately also get closed for non-delivery, non-payment etc.
One thing is for sure. Contracts must be closed one way or the other. In order to eliminate risks to both parties, closing the contract makes certain nothing else is going to be delivered or paid under the contract.

Let me try to explain this in non-technical terms (or as close to it I can get).

1-Tier Architecture

We all know software packages like MS Access, MS Excel, QuickBooks, and Peachtree just to name a few. They all have the same in common that they access files directly. This means that the file you want to work with must be accessible from a local or shared drive. This is the simplest of all the architectures, but also the least secure. Since users have direct access to the files, they could accidentally move, modify, or even worse, delete the file by accident or on purpose.

There is also usually an issue when multiple users access the same file at the same time: In many cases only one can edit the file while others only have read-only access.

So 1-tier architecture is simple and cheap, but usually unsecured and data can easily be lost if you are not careful.

2-Tier Architecture

This architecture is also called Client-Server architecture because of the two components: The client that runs the application and the server that handles the database back-end. When the client starts it establishes a connection to the server and communicates as needed with the server while running the client. The client computer usually can’t see the database directly and can only access the data by starting the client. This means that the data on the server is much more secure. Now users are unable to change or delete data unless they have specific user rights to do so.

The client-server solution also allows multiple users to access the database at the same time as long as they are accessing data in different parts of the database. One other huge benefit is that the server is processing data that allows the client to work on the presentation and business logic only. This mean that the client and the server is sharing the workload and by scaling the server to be more powerful than the client, you are usually able to load many clients to the server allowing more users to work on the system at the same time.

3-Tier Architecture

This involves one more layer called the business logic tier, service tier or middle tier (layer). In the client-server solution the client was handling the business logic and that makes the client “thick”. A thick client means that it requires heavy traffic with the server, thus making it difficult to use over slower network connections like Internet and Wireless (LTE, 3G, or Wi-Fi).

By introducing the middle layer, the client is only handling presentation logic. This means that only little communication is needed between the client and the middle tier making the client “thin” or “thinner”. An example of a thin client is an Internet browser that allows you to see and provide information fast and almost with no delay.

As more users access the system a three-tier solution is more scalable than the other solutions because you can add as many middle tiers (running on each own server) as needed to ensure good performance (N-tier or multiple-tier).

Security is also the best in the three-tier architecture because the middle layer protects the database tier.

There is one major drawback to the N-tier architecture and that is that the additional tiers increase the complexity and cost of the installation.

Take a look at the differences among these three.

So we have a detailed description of the scope (the design of the software); where do we go from here? We need to break down the project deliverables into progressively smaller components so they are easier to estimate for time and cost. This is also called decomposition and the resulting structure is called Work Breakdown Structure or simply WBS.

In the WBS, the top layer is of general nature and each subsequent layer gets more and more specific until we are left with small units (or packages) that easily can be estimated for time and cost and at the same time provides enough information to proceed with subsequent activities.

At the bottom of the Work Breakdown Structure are nodes or so-called WBS packages (work packages). So when does a node become a work package? Here are some pointers:

• The work package can’t be decomposed any further
• The work package is small enough to be estimated for time and cost
• The work package can be assigned to a single person

The resulting WBS is a graphical, hierarchical chart where each node has a number to uniquely identify it.  If you are using Microsoft Project or other project tools, the WBS is also often shown as a so-called Gantt chart where each indention is a step down in the hierarchy until we reach the final work package.

Once the WBS chart has been established, we need to document the content of each package. For that purpose we must create the WBS Dictionary.  The dictionary includes a detailed description of each node and can also include whom it is assigned to, dates, cost, etc.

So what makes a good Work Breakdown Structure? Here are some pointers:

• The work package should be very detailed since they all define every deliverable on the project
• It is hierarchical like a pyramid (or Gantt chart)
• Each node should have a unique number and the numbering system should be logical to allow anyone to find the nodes easily
• It is thorough and complete. If something is not on the WBS, it does not get delivered
• The project team builds the WBS, not just the Project Manager