Drawing an Activity Network Diagram for a Project – an Overview

After you have identified various activities of the project and defined the sequence in which these activities should be carried out along with the due relationships existing among the activities, the next step is to draw a network diagram that is a graphical representation of the sequence you have identified for the activities. When you draw a network diagram of the project activities, you use various nodes representing various activities that are connected to each other with arrows based on the relationship you have identified among these activities.

A network diagram is one of the most common tools used in project management. Even though you have identified the sequence of activities, it does not help you to channelize your efforts until you have created a network diagram. The network diagram helps you to identify the critical path of the project. A critical path defines the sequence of project activities that add up to the longest sequence of activities that you must perform to complete the project. The critical path indicates the shortest duration that the project would take to complete it.

The entire network diagram is enclosed between two nodes indicated by the Start and End nodes. To identify the critical path of the project, you consider various project sequences of activities right from the Start node till the End node. The sequence of activities that take the longest duration is considered as the critical path of the project.

When creating a network diagram, you also mention the duration for each activity. When you add up the duration of each activity of the critical path to identify the minimum time the project would require completing it from start to end.

You can use any of the following methods and techniques to create an activity diagram for a project:

  • Drawing Network Diagrams by Using the Precedence Diagramming Method: Also known as Activity on Node method, this is the most common method used to draw network diagrams across the projects. In this method, you create nodes or boxes that represent activities and connect these nodes by using arrows that show the dependency between the activities these arrows connect.
  • Drawing Network Diagrams by Using the Arrow Diagramming Method: Also known as Activities on Arrows method, when you create a network diagram by using the arrow diagraming method, you use arrows to represent activities instead of nodes in the resultant network diagram.

Drawing Network Diagrams by Using the Graphical Evaluation and Review Technique (GERT) Diagramming Method: The Graphical Evaluation and Review Technique (GERT) diagramming method is a modified network diagram that enables you to create loops between the activities. You use this method when any of the project activities are recursive. For example, after designing you need to test the design. However, when a gap is identified in the testing phase, you need to revisit the design phase. You can represent such recursive relation between the design and test activities by using the GERT diagramming method.

Sequencing Activities of a Project

After you have identified and defined activities, the next logical step is to identify the sequence in which these activities should be carried out. Therefore, the Project Management Book of Knowledge (PMBOK) published by the Project Management Institute (PMI) has defined the next process as the Sequence Activities process. In this process you define how the actual work for the project has to be carried out.

Before you start sequencing the project activities, the first task in hand for you is to identify and define relationship among various project activities. The relationships among the project activities indicate how these activities are related to each other, such as dependencies of the activities on each other. For each activity, you decide on an activity that is a predecessor – an activity that should be completed before you start the current activity, and a successor – an activity that should follow the current activity.

Additionally, there would be some activities that can be performed simultaneously. However, it is not necessary that the activities performed simultaneously must start or end at the same time. Depending on the predecessor of the activities, each activity has its start time. Similarly, the end time of the activity depends on time period required to complete the activity.

Depending on the sequence at which you can complete the activities, you can classify the relationship that can exist among various activities of the project into the following categories:

  • Finish to Start: Finish to start is one of the most common relationships that exist among the project activities. In this type of relationship, an activity can start only after the predecessor activity is complete.
  • Start to Start: In this type of relationship, an activity cannot start before the other activity starts. This type of relationship usually requires both activities to start at the same time and run parallel to each other. Unlike finish to start relationship, this is the least common type of relationship among the project activities.
  • Finish to Finish: In this type of relationship, an activity cannot finish before the other activity finishes. This type of relationship usually exists between the activities that are the predecessors of the same activity or the completion of one activity is an input for the completion of another activity.
  • Start to Finish: In this type of relationship, an activity must start before another activity finishes. This type of relationship usually exists between the activities where start of an activity is an input for the completion of another activity.

After you have derived relationships among the activities of the project, you get a sequence that creates a network of activities interlinked with each other based on their relationship. This network of the project activities is known as network diagram of the project.

Defining Activities of a Project

The Define Activities process is used to further work on the work packages of the work breakdown structure. You use this process to break down a work package further to the activity level. An activity of a project is a small enough unit that you can estimate, schedule, monitor, and manage efficiently and effectively.

Often, the define activities process is merged with the create work breakdown structure process by drilling down the work breakdown structure itself to the activity level instead of stopping at the work package level. The next important process that follows the define activities process is the Create the Network process. One of the reasons that you might not want to take the project to the activity level is because of the fact that creating a network diagram based of the large number of activities defined in this process results in a large network diagram that you might find difficult to manage. As a result, you might want to decide on creating a network diagram based on the work packages identified in the work breakdown structure.

Whether you create a network diagram from the work packages identified in the work breakdown structure or form the activities you have defined after drilling down the work packages of the work breakdown structure, none of these approaches is incorrect. However, it is always advisable to define activities before you derive a network diagram and manage the project more effectively.

To define activities for the project, all you need is an approved scope statement and the work breakdown structure for the project as an input for the process. The approved work breakdown structure includes the work breakdown structure dictionary as well as the work breakdown structure diagram. It is always advisable to involve your team when defining activities for the project to make sure that you define complete and accurate activities. This would make sure that your estimates are more accurate and realistic.

There is no hard and fast rule when you should plan the lower level details. You can either plan it in advance or plan for the higher level and then wait till you start with the project and things become clearer before you plan for the lower level. The latter approach is however more recommended because the former one might result in rework and waste of efforts. The process of planning at the later stages as the project proceeds is known as rolling wave planning because it involves multiple waves of planning as and when various details are finalized.

Whatever option you select for the project planning, you must be confident about it. Later down the line, you must not put it forward as a reason for improper planning and failure of the planning. After you have complete the define activities process, its outcome is the list of activities and their details in the form of activity attributes. Defining activities would helpful in defining milestones of the project in due course of the project life cycle, which are significant for the overall project schedule.

An Introduction to the Schedule Management Plan

Schedule management plan is yet another important and integral part of the overall project planning. In the Project Management Body of Knowledge (PMBOK) guide published by the Project Management Institute (PMI), the plan for schedule management in not identified as an individual entity of the scheduling process. However, it is considered as a part of the Develop Project Management Plan process.

Difference between Project Schedule Management Plan and Project Schedule

When creating a schedule management plan, you need to consider the methodology you need to use for creating the plan. At times, an organization has a well defined methodology that a project manager must use to start creating a schedule management plan. These predefined methodologies usually form a part of the organizational process assets. After you have decided on the methodology to be used to create a project management plan, you need to decide on the tools you should be using to create the plan. Again, as a part of the organizational process assets, the organizations might have an approved set of tools that the project management team is expected to use to create a schedule management plan. Another important aspect of creating a schedule management plan that you must consider is to decide on how you intend to manage and control the project schedule.

Schedule Management Plan

When creating a schedule management plan, you should include the following components:

  • The scheduling methodology that you intend to use to create the schedule management plan
  • The scheduling software that you intend to use to create the project schedule
  • An established schedule baseline that you would use to measure actual time lines against it when monitoring and controlling the project schedule
  • Performance measures that must be used to monitor and control the project and identify the variance well in advance
  • Plan for managing the schedule variances
  • Definition of the procedure for schedule change control

It is a must that you create a schedule management plan that suits the project execution policy of the organization. The project execution policy can include the requirement to safeguard costs incurred due to time, control the overall budget of the project, control for the change management, control on the resources, comprehensive management usage, coordination and control between the owner and third party, predicting and projecting project status accurately, documentation, and avoiding claims from the customer. The main objective of creating a schedule management plan is to develop an organized and focused project schedule.

Creating a schedule management plan makes sure that you develop a project schedule that is a result of a process with a great consideration of the overall prevailing conditions. Such a project schedule management plan considers the organizational structure and results in an efficient schedule.

Difference between a Project Schedule Management Plan and Project Schedule

It is common that there is a confusion between a project schedule management plan and project schedule. Many a times, these are considered to be the same. However, this is not true. There is a subtle difference between the two.

Creating a schedule management plan consists of the efforts you put in planning and designing a project schedule. It also includes the efforts you put in identifying and defining the end user, designing reports, identifying the work breakdown structure, identifying the activities, defining the frequency at which you can update the project details, and the level of details required for developing the project schedule. It also includes your decision to use bottom up or top down approach that you should be taking to develop the schedule.

On the other hand, developing a project schedule refers to the development of the baseline schedule for the project. Development of the project schedule is directly related to the project schedule management plan. The better is the project schedule management plan, better is the development of the project schedule.

What is Time Management – an Overview

It is an old saying that time is money. This holds true for any business organization too. Therefore, it becomes more and more important for business organizations to manage time in their day to day activities. As a project manager, you cannot afford to manage a project that runs till eternity. You can neither afford a project that does not have well defined time lines nor a project that has unrealistic deadlines that cannot be achieved. Therefore, one of your main responsibilities as a project manager is to manage the project time effectively and productively.

Time management is an important aspect of the project planning where you plan and organize the project time among various project activities. You use time management as a process to plan and consciously control the time you spend on a specific activity of the project to make sure that you increase its productivity, effectiveness, or efficiency. Additionally, time management helps you to maximize overall benefit of the activity within the limits of the allocated time period. Time management does not mean that you manage the time, which is not possible because it is fixed. You get only 24 hours in a day and can never alter the fact. However, with the time management, you focus on managing the project activities with respect to the available time.

Time management enables various benefits that you can derive into a project. It helps you with enhanced productivity and efficiency of the project. As a result, time management helps you to gain a great professional reputation among the management, colleagues and customers. With project running on track because of proper time management, you get less stressed out due to the high probability of the project meeting the required deadlines. Moreover, as a result of your professional reputation, you get more opportunities to advance your career and other life goals.

On the other hand, if you do not manage the project time effectively, you can expect some undesired consequences. These consequences includes, missing internal as well as final deadlines of the project, inefficient work flow of the project that can further result in quality issues as well as lower customer satisfaction, and overall poor quality of the project. Moreover, on the personal front, it can earn poor professional reputation for you that can hamper your growth chances and stall your career. Missing deadline over deadline as a result of poor time management can put you in a lot of stress.

When implementing time management process in a project, you use a mix of skills, tools, and techniques to manage time for accomplishing specific activities within the given time frame. It not just the project management where you use the time management process, but you can even use this process to mange time for your personal activities too.

In the recent times, time management has become an integral part of the project management and determines the project completion time and scope. Some of the tasks that you perform in the time management process include:

  • Defining activities of the project
  • Sequencing the activities
  • Drawing network diagram
  • Estimating the duration of activities by using various tools and techniques
  • Developing a schedule
  • Analyzing the schedule by using various tools and techniques
  • Defining the project schedule
  • Controlling the project schedule

Creating a Mind Map for the Project Requirements

A mind map is a powerful tool that you can use to represent the requirements of a project. It is a graphical tool that you use for the visual representation of the project requirements. Additionally, a mind map is a hierarchical representation of ideas, and depicts the relationship among all components of the project. When you create a mind map, you start from the center of the mind map by specifying the central idea, such as the name of the project. You keep associating related ideas to the central idea as its branches. To depict ideas and their branches, you can use various pictures, words, and even part of words.

Users across industries use the mind map technique for a visual representation of their ideas. Each branch of the mind map flows like a story line from center to the last node and provides the complete understanding of an idea. Moreover, a mind map is quite flexible. You can add a branch to a node when you get an additional idea or remove a branch from any node that is not required. The same concept of a mind map is true for a project. When collating and understanding the stakeholder requirements, you can use this technique to map the related requirement as various branches of the project and keep elaborating the requirements as sub branches of each requirement. This not only enables you to understand the stakeholder requirements, but also correlate various requirements because of visual representation of the requirements.

After you have finalized a mind map for the project, you can map these requirements to various components and deliverables of the project, including the processes to be followed to complete these deliverables. The mind map of a project provides a bird’s eye view of the project that you can present to the stakeholders to verify your understanding of the requirements with respect to the requirements you have received from them. Moreover, you can visualize the product and its features with the help of a mind map.

You can either create a mind map manually on a sheet of paper or use any of the automated mind map utilities available commercially. While you can use your artistic sense in the manual system, you can use the advanced technology and features of the automated system, such as collapsing various levels of nodes individually, which gives larger clarity and control when presenting it to the stakeholders. Whatever utility, manual or automated, you use to create a mind map, the basic procedure remains the same. You start form the center as the title of the project and expand it in the radial hierarchical format. One complete branch of the radial hierarchy usually maps to a major feature of the project, though it can map to more in case of related ones.

Generic Guidelines to Create a Mind Map

When creating a mind map, whether for the project requirements or otherwise, you must adhere to the following guidelines:

  1. Start from the center of the mind map and add the project title to the represent it. You can depict the project title by using a graphic or just a simple box along with the title.
  2. Start adding main feature to the mind map, which depict high level features of the product and service, as the branches of the project. You can use various images to depict these features. Additionally, to distinguish these branches, you can use different colors for each branch.
  3. Select and use key words to depict each set of requirements.
  4. Each key word must be unique and belong uniquely to each branch.
  5. Start connecting lines from the central image to the branches. These lines usually get thinner and thinner as you radiate out from the center.
  6. Create the length of the lines that matches the words or images they support.
  7. Use multiple colors to distinguish branches from each other. You can also use these colors to encode as well as group the requirements.
  8. There is no fix style of creating a mind map. You can create your own style for the same.
  9. Use emphasis and indicate associations in the mind map to enhance the understanding of the related requirements.
  10. Avoid any cluttering in the mind map and keep it clean to make sure that there is no ambiguity or miscommunication.

Controlling the Project Scope

The Control Scope process is yet another important process defined in the Project Management Body of Knowledge (PMBOK) guide published by the Project Management Institute (PMI). This process enables you to measure the performance of the project and product scope. Additionally, the process enables you to manage the scope baseline changes. The baseline of the project scope is the project scope, the work breakdown structure, and work breakdown structure dictionary that you have negotiated and agreed upon with the stakeholders of the project. The measurement of the success of the project as well as the project manager depends on how well the requirements of the project are met and how well the scope baseline is adhered to. The scope baseline is the part of your project management plan and must be approved by the stakeholders of the project.

As a project manager, it is one of your responsibilities to frequently measure the scope and make sure that the project is being completed as per to the project plan. You must remember that the project scope baseline by itself is your project management plan. One of the most important requirements for controlling the project scope is to make sure that you have a complete and clear definition of the project scope. For this, you must know of the requirements documented in the requirements document as well as the requirements traceability matrix.

Then, you need to measure the performance of the scope as against the scope baseline and verify the level of variance, if any. Depending on the variance, you need to make a decision if taking either a corrective action or a preventive action is required to control the scope. After you have decided on this, you need to determine if you need to make any updates to the scope baseline or any other project document including the project plan, and as a result decide on the changes that should be requested to control the scope. Additionally, consider the impact that the changes to the scope make on the other aspects of the project.

The control scope process is proactive rather than being reactive. You must think about the source from when the change requests are frequently generating for the project and make sure that you prevent or eradicate the need for any further changes from such source.

Your role as a project manager is not to process change requests from various stakeholders. You must control the project as per the project management plan and make sure that you meet all baselines defined for the project. Therefore, you must not get influenced by the stakeholders and keep adding to or changing the scope of the project. If the need is there, you must make sure that you follow the change management process, and also that the change requests are well within the planned scope of the project. It is a common practice that stakeholders make multiple attempts to influence the project by requesting changes to the scope of the project. As a project manager, it is your responsibility to make sure that you must control the scope of the project and not make any changes that impact the scope and deviates it from the planned scope of the project.

Verifying the Project Scope

According to the Project Management Body of Knowledge (PMBOK) guide published by the Project Management Institute (PMI), Verify Scope is an important process. As the process name indicates, verify scope does not mean that you make sure that you have correct scope of the project during the planning phase. However, you use this process to make sure that you get a formal acceptance of the scope from the stakeholders of the project. The verify scope process might need you to plan frequent meetings with the stakeholders, such as project sponsors and customers, to get a formal acceptance on the deliverables during the monitoring and controlling phases of the project management.

The verify scope process enables you to make sure that the customer understands that the project is on track even when work is in progress on the project, instead of waiting for the acceptance at the end of the project during the project closure phase. It is always better for you to identify changes and issues, if any, when work for the project is in progress instead of finding these at the end of the project life cycle when looking for the project closure. This not only saves on your project time and efforts, but also makes sure that the stakeholders are on the same page, and are updated on the status of the project and its deliverables. As a result, it gives you an opportunity to get the acceptance of the stakeholders on the deliverables or get a change request well in time.

Whether it is acceptance of the deliverables or change request, you must update the documents of the project to indicate the completion of the deliverables or change request for the deliverables. This indicates that the verify scope process has three outputs – acceptance for the deliverables, request for changes to the deliverables, and updates to the project documents.

It is not necessary for you to wait till the end of the life cycle of the project or even the deliverable to verify the scope. You can run this process at the end of every phase of the project life cycle, including the monitoring as well as controlling process groups of the project management. This makes sure that you verify the deliverables of each phase when work is in progress. Additionally, it is not necessary that you verify scope only once during the project life cycle. Instead, you should do so multiple times during the project life cycle. You must keep in mind that the acceptance during the verify scope process is the formal acceptance only for the interim deliverables. However, you get the final acceptance of the complete project as a part of the formal acceptance and sign offs of the project deliverables during the project closure phase.

You must also run the verify scope process after the Perform Quality Control process. In the perform quality control process, you make sure that the product meets the quality standards, as agreed upon for the deliverables. However, with the verify scope process, you make sure that the customer checks the deliverable and formally accepts it. Even though both the processes check the quality of the deliverables, the difference between the two is based on who performs the quality check. While quality check is done by an internal team in case of the perform quality control process, the customer checks the quality of the deliverables in case of the verify scope process. After checking the deliverables, the customer either accepts the deliverables or requests for a change. The cycle continues until the customer formally accepts the deliverables.

Defining a Work Breakdown Structure (WBS) Dictionary

When you manage an enterprise level project, one of the deliverables of the project planning phase is the work breakdown structure. The ultimate level of the work breakdown structure is a work package. In an enterprise level project, the work breakdown structure is quite large and has a large number of work packages. It is not only the large number of work packages that is a matter of concern, but the fact that you might need to make frequent changes to these work packages is another concern. Therefore, it might involve a lot of efforts and confusion to track the current status of these work packages. As a result, you need some mechanism that enables you to manage these work packages efficiently. Moreover, a work breakdown structure is a graphical representation of the project to provide its bird’s eye view. You cannot add much detail into it because it might impact clarity of the graphical work breakdown structure.

Work breakdown structure dictionary is such a mechanism that enables you to efficiently track each element of the work breakdown structure, including work packages of a project. Similar to a dictionary of a language that organizes and provides details of the words that make the language, a work breakdown structure dictionary organizes and provides complete details of all work packages of a project. A work package usually has a small name comprising of one or just a few words. Such name does not provide complete details about the work package and is open for interpretations, which can be ambiguous and add to confusion. This can further result in miscommunications in the team. The dictionary enables you to provide complete details of the work package. These details include a detailed description of the work package, its identification number, acceptance criteria, dependencies, schedules, and other details related to the work package.

A work breakdown structure dictionary entry of the work package not only enables you to identify and track the work package, but also provides complete information about the work package to the team to understand what the work package is and what its deliverables are. These details help the team to be on the same page to understand the work project and avoid any miscommunication. You can use it to control the work done for the work package, and make sure that its scope is not changed and adhere to the schedule specified for the work package.

Depending on the organizational policies, you can design the data dictionary entry and details you need to add to it. You can either create a worksheet in an Excel or any other spreadsheet application, or create a table for each entry that consists of all details of the entry. Following is a sample template for a work breakdown structure dictionary entry along with the details required for the entry:

 

Work Breakdown Structure Dictionary Entry
Control Account No.

<Specify an identification number for the control account that the work package belongs to>

 Work Package No.

<Specify an identification number for the work package>

 Updated on and by

<Specify the date when the work package was last updated and the person who requested or made the change>

 Responsibility

<Specify the name of the person or organization responsible for the work package>
Description: <Add a detailed description of the work package>
Acceptance Criteria: <Specify the details of the criteria to be used as an acceptance for the work package>
Deliverables: <Specify the details of the deliverables expected from the work package>
Resources: <Specify the resources assigned to the work package>
Assumptions: <Specify the assumptions made for the work package>
Duration: <Specify the planned duration for the work package>
Milestones: <Specify the details of the milestones scheduled for the work package>
Cost: <Specify the planned cost of the work package>
Due Date: <Specify the planned end date for the work package>
Interdependencies

Previous work Package: <Specify the work package that must be complete before this this package. >

Next work package: <Specify the work package that depends on the completion of this work package. >
Approver: Project Manager <Signature of the project manager> Date: <Date of approval>

Note: To keep track of the changes made to the work package entry, make sure that an incremental update is made rather than overwriting the existing content. This would help you to trace the changes made in case of any conflicts in the future.

Creating a Work Breakdown Structure (WBS) for a Project

Work breakdown structure of a project is a created by decomposing its stages hierarchically and incrementally into various phases, deliverables, and work packages. It is an inverted tree structure that has branches representing subdivisions of all the efforts required to accomplish an objective that is represented by the root of the inverted tree.

You create a work breakdown structure of a project by starting with the end goal of the project and then keep dividing it into chunks of manageable components. You can create these components based on the size, duration, and responsibility. When dividing the project into manageable chunks, you must make sure that these include all steps that are necessary to accomplish the end goal of the project.

You usually start a work breakdown structure with the project tile at the top or the root of the inverted tree structure. Unless you have some specific stage, the next level of the structure is typically represented by various stages of the project life cycle, such as initiation, planning, execution, control, and closure. From the next level onwards, you keep breaking the stage into further level until you get a chunk that is small enough to manage.

The inverted tree looks more like an organizational chart of a company. However, it is not an organizational chart. When managing a project you would realize that it is too big for an individual to manage the entire project as a single chunk. Therefore, you use the work breakdown structure to break the project into small chunks that are easy to manage. The work breakdown structure is a top down effort of decomposing the deliverables along with the work that needs to be performed to produce these deliverables. These small chunks are known as work packages. When defining a work package, make sure that you define it based on the work package name, which should be a noun, and not an action, or verb, to be performed.

When creating a work breakdown structure, you assign an identity number to each unit in the structure. It usually starts with 1 for the root level and then an additional number separated by a dot, such as 1.1, 1.2 and so on for the units of the second level, as shown in Figure 1. The multilevel number continues to increase with each level of decomposition until work packages are defined.

A work breakdown structure is oriented toward the deliverables. However, keeping the work breakdown structure that is oriented toward the deliverables does not mean that you should include only customer deliverables. You must include the complete scope of the project in the work breakdown structure. This includes project scope, product scope, and project management efforts.
 

Advantages of a Work Breakdown Structure

One of the most important objectives of creating the work breakdown structure is to provide a framework for dividing work into definable units of work. You can use this structure for overall planning and control of the project and even to define the statement of work. Further, you can use the work breakdown structure to establish schedule, cost, and labor hour reporting.

A work breakdown structure also enables you to sum subordinate costs of the tasks and materials of the components into the tasks and materials of the parent component. You must provide a description of the tasks to be performed for each element of the work breakdown structure. You can also use the work breakdown structure to define the complete scope of the project.

Additionally, a work breakdown structure provides the team members a complete understanding of how their work fit into the overall project plan and what they need to do to achieve it. It also fosters a communication and cooperation among the team members.
 

Rules to Create a Work Breakdown Structure

When creating a work breakdown structure, you should consider the following set of rules:

  • You must involve and take help of the team to create a work breakdown structure.
  • You must complete the first level before you break the project further to the next levels.
  • You create a smaller chunk in a level with respect to the previous level.
  • Each highest level of the work breakdown structure represents the complete project. It is not necessary for you to break each level further down unless you can break it further into smaller manageable chunks.
  • You must include only deliverables that are actually needed for the project in a work breakdown structure.
  • The deliverables that you do not include in a work breakdown structure are not part of the project.

 

Identifying a Work Package

When creating a work breakdown structure, you can identify a work package when they include deliverables that have following characteristics:

  • You can estimate a work package realistically and confidently.
  • You can complete a work package quickly.
  • You do not need any further information for a work package and can complete it without any interruption.
  • You can outsource a work package.

 

Sample Work Breakdown Structure

Following is a sample work breakdown structure for an Android application project up to the third level of decompositions:

Figure 1 Work Breakdown Structure for an Android Application

Exit mobile version