Logo for SK Enterprises

S K Enterprises' Synapsis System Help Section
 

Project Manager

  1. Starting a project.
  2. Creating tasks.
  3. Assigning resources.
  4. Entering and tracking costs.
  5. Examining the project.
  6. Tracking the progress of the project.
  7. Generating reports.
  8. Some project management basics.


VIII. Some project management basics.

This section of the Synapsis Project Manager Help pages is designed to provide a brief introduction to the field of project management. This piece is an on-going effort and will be expanded and fleshed-out as time progresses. The goal of this section is to present a quick overview of project management fundamentals so that users of Synapsis Project Manager that are not well versed in the principles of project management can have a resource within the module.
  1. The project.
  2. Tasks.
  3. Resources.
  4. Budgets.
  5. Managing the project.
  6. Reporting.
  7. Changes during the course of the project.
A. The project.

The first thing you need to do is develop a definition of your project. Since, by definition, a project is a temporary undertaking to solve an existing problem or take advantage of an existing or new opportunity, you should start by creating a clear, concise definition of the problem or opportunity. Use this moment to distinguish between what is actually needed versus what may also be desired. Take care to connect the problem or opportunity to the needs of the business.

The next step is to create a statement of the project objective. This involves answering the basic what, when, how questions. This project objective statement should be complete, with a measurable objective (or several measurable sub-objectives), and, if possible at this point, be constrained by time and, or budget considerations. Now is also the time to put together a project strategy, which is a statement enumerating action syou will take to complete the project you outlined in your project statement.  You should also use the project stratgey statement to discuss potential risks faced by the project. Make sure you include objectives, which can be measured.

B. Tasks. (top)

It is now time to generate a list of tasks, which, when all are completed, will result in the completion of the project. There are several ways to generate a description of the tasks that comprise your project. One way is to create a tree-structure with work categories. Another way is to create a "pseudo" sequential list of 'things' that have to happen in order to complete the project. These 'things' can be general or specific. Next, look at each individual 'thing' and and make of list of 'sub-things' that go into finishing each 'thing.' Sounds kind of vague, so let's take an example. Say you wanted to build a standard, low-cost desktop computer. What 'things' need to happen?
  1. Assemble materials.
  2. Put materials together.
  3. Test sysetm.
We've identified three 'tasks.' Now let's develop these further.

1. Assemble materials:
  1. Decide desired system specifics.
  2. Make a list of parts.
  3. Obtain prices for parts from various vendors.
  4. Purchase parts.
2. Put materials together:
  1. Attach CPU chip to motherboard.
  2. Attach heat sink and CPU fan to CPU chip.
  3. Attach CPU fan power cable to motherboard.
  4. Insert RAM chips in motherboard slots.
  5. Attach motherboard to CPU case.
  6. etc. ...
3. Test system.
  1. Plug in power supply.
  2. Turn power switch to "On" postion.
  3. Check BIOS settings.
  4. Place OS medium in proper I/O (CD-rom, floppy drive).
  5. Boot system through OS medium.
  6. Install OS.
  7. etc. ...
The most important factor is to try and be as detailed as possible the further you drill down into the project activities. Make sure that you record all activities, and that each activity is recorded only once. Once you have developed a comprehensive, detailed list of activities you must next decide what level of detail you will use for defining your project tasks. This aspect of project management is as much art as it is science, but there are ways to help you make these decisions. First, ask yourself whether or not it is appropriate to identify and estimate the resources necessary to complete a particular activity. If your activity is defined too broadly, you will have trouble estimating how long it will take and how many resources are needed to accomplish it. You will also end up with too long a list of relatively unrelated resources listed as needed to accomplish the task. If your activity is defined to narrowly, you will find that it is tough to estimate how long the activity will take to accomplish because the time needed will be so short that you will most likely end up over stepping the end of the project because the sum of the durations of all of your small activities will be a lot more than the duration of the project itself. You will also find that many of your resources are assigned to strings of tasks, one right after the other. Second, ask yourself whether it is possible to make reasonably good estimates of how long it will take to finish the activity. Finally, the activity should not be too complex. Meaning, does it take pages and pages to explain the activity? If so, then it probably needs to be sub-divided into smaller activities.

The next step is to gather specific information on each activity that you have recorded in your list. The information you will need includes:
You will note that this list of information requires a couple of things. First, coordination and cooperation. Unless the project or activity is very simple, it is likely that you, as project manager, will lack the technical knowledge to generate all of the information required on the list. This means that you will need to coordinate a team, which requires the cooperation of team members to gather all of this information. The only advice we can give is for you to be as careful as possible in gathering this information, especially the time required and the amounts of resources needed. You may wish to get three estimates, pessimistic, most likely, and optimistic, along with some reasons for the differences. These reasons might give you some indication of whether or not the team member(s) creating them have much experience with this type of activity.

After you have finished gathering all the information for each activity, you are ready to construct your "network diagram." The network diagram is used to map the proper sequence of activities, and is simply a flow chart of all the activities described within your project. Most project managers use one of two types of network diagrams. They are similar and both involve relating one activity to another using arrows. One method makes each activity a 'node' on a tree with an arrow extending from that 'node' to the next 'node' (activity) in the sequence and with the point of the arrow aimed at the subsequent 'node.' The other the 'nodes' are events, or breaks between activities, and the arrows are themselves the activities. "Events," also called milestones, are actions that take no time or resources - they just happen. Of course, these nodes don't need to be events and don't even need labels, they can simply by the point where one activity ends and the next begins. In either case, the goal is to create a flow of your project from activity to activity until the end, making sure you capture the correct sequence. The idea of the arrows is that if there is an arrow from one activity to another, you can't start the next activity until the first one is completed.

The network diagram is used to calculate the following:
  1. The "critical path," which is the sequence of activities that takes the longest time to complete.
  2. A "critical activity" is an activity that is part of the critical path.
  3. "Slack" or "float," which is the amount of time an activity can be delayed from finishing without extending the project duration.
  4. The "earliest start" is the earliest time you can start an activity.
  5. The "earliest finish" is the earliest time you can finish an activity.
  6. The "latest start" is the latest time you can start an activity and finish the project on-time.
  7. The "latest finish" is the latest time you can finish an activity and finish the project on-time.
When calculating the "critical path" you must insure that you have accurately defined all of the pre- and subsequent task conditions, i.e., which tasks must occur before the current task, or which tasks must occur after the current task. These are defined as:
To calculate the project's critical path, begin by calculating start and end times for each activity (beginning at time=0) and using the estimated durations for each activity along with the pre- and subsequent-task conditions. The time when the last activity is completed then becomes the finishing time you will use to calculate the "latest" finish and start times for every activity working from finish to start. So, using the finish time, the estimated activity durations and the pre- and subsequent-task conditions and working backwards, calculate the start and finish times of each task. Next you determine the slack or float for each activity by either subtracting the earliest start date from the latest start date, or subtracting the earliest finish date from the latest finish date. If an activity has 0 slack, that activity is on the critical path.

The critical activities are the activities that you will need to manage more carefully because if one of them slips, the project will slip. After you have created your network diagram and identified all of the critical activities and activity start and end dates, you are ready to create your task schedule using those dates. You can then evaluate your new schedule with the overall project time frame to verify that you can actually complete the project on-time.

C. Resources. (top)

Now that you have listed all of your project's tasks, identified task conditional relationships and created your network diagram, you must begin to estimate and identify all of the resources you will need to complete all of the tasks in your project. The first thing you need to do is identify the skills required to preform each task. Make a list of each skill along with the task name. Next, make a list of the names of all of your resources and match up each resource to all of the skills they possess. You should also note the resource's skill level and the required skill-level, so that you don't assign a resource without a sufficiently high skill level to a task that requires a higher one.

Next estimate how much time you need for each resource on each task. Keep in mind that the sum of the person (resource) hours required for a task may exceed the number of work hours in the task's duration. For each resource listed under a task, estimate the amount of work hours that the resource will need to devote to the task/skill. When you're done, compare the work hours for each resource and make sure they don't exceed the work hours for the task, if they do, then you won't be able to complete the task in the alloted time. One important note, remember that it is unlikely your resources will be able to spend 100 percent of the time assigned working on the project, particularly if you assign them 100 percent to the project. Workers spend between 2 and 4 hours of an 8 hour work day doing non-project-related administrative and other activities.

At this point, you should also check the work calendar for each resource to look for times when your resource is "over-committed" (for example, scheduled to work more than 8 hours in a day). If you see this, you can try "resource leveling." There are a couple ways to level a resource:

If these options aren't available, you may have to resort to overtime payment. You should also take into account other projects a resource might be assigned to work. After you have assigned all of the resources and leveled their work loads, re-examine the overall task flow and project to verify that your original schedule is still viable. If not, you'll have some more adjustments to make by either re-working resources, or re-defining task or project schedules.

D. Budgets. (top)

After assigning resources to each of the project tasks, you can now start looking at costs. You may need to take into account two types of costs, direct costs and allocated costs. Direct costs are, simply, those costs which you can attribute to your project from the direct assignment of resources to tasks. These include things like materials costs, and hourly wages. Allocated costs are costs that can be assigned to your project, but are incurred indirectly. These include things like depreciation, supports costs and things. You may not need to consider allocated costs, or they may simply be assigned to the overall cost of your project, or you may have to estimate them along with direct costs.

Direct costs are more straightforward. Use your task-resource assignments and estimate how much each assignment is going to cost, add up each assignment for a task to get the task cost, and then add up the costs of all the tasks. You should include any set, fixed, or one-time costs in your calculations as well. These would include things like a resource signing bonus, a license cost etc. Allocated costs aren't necessarily more difficult to estimate. For example, say you have to include the "fully loaded" cost for portions of all of your human resources. This would include things like benefits. A lot of companies have set percentages that apply, like 50 percent of the employee's wage. So you would merely add up the portion of the resource's full-time employment that the resource is assigned to your project and multiply that by the resource's "loaded" cost. You can end up in some interesting arguments regarding allocated costs, particularly if your project is being subject to a cost-benefit analysis. For example, say the resource you are using, is not scheduled on any other income producing projects during the time he or she is assigned to your project. You might ask why it would appropriate to charge the loaded cost of the resource to your project, when the company will incur that cost whether or not the resource works your project. In any event, once you have completed the cost calculations, you will have a baseline project budget that you can track against over the course of your project.

E. Managing the project. (top)

Once you've gotten this far, you're ready to establish a management structure, process, and kickoff the project. The first thing you will want to do is decide upon a management structure, which is simply an organizational structure. Because your project itself is like a small business, you have a wide variety of organizational choices. Some of the choices are: hierarchical, functional, matrix, network, and free form. Briefly, the hierarchical structure is a layered form typical of most businesses where authority flows from top to bottom (with you presumably being at the top); the functional structure duplicates some functions across different units, rather than having those functions themselves be separate units; the matrix structure mixes hierchical and functional forms by allowing for dual control by separate functional managers and hierarchical managers; and the free form structure is just what the name suggests, it can resemble any other type of structure, but individual members are given the freedom and encouraged to implement their own ideas.

From your project perspective, as you look at the tasks and resources in your own project, you will observe that resources can be grouped somewhat by what they do, and that resources within a group are assigned across multiple tasks. You can choose the management structure for your project. However, you might also have to consider the management structure of your company. Most, if not all, of the resources report to one or more bosses - these bosses might be functionally aligned with what the resource is doing on the project, or they might be more generally placed. You have to sort through how you relate, as project manager, to the resources' hierarchy, and how that relationship is situated within the leadership of the company. It won't help you if your resource, who's working on a critical task, is suddenly pulled away for a "fire drill" by their direct superior. These managerial and organizational issues must be worked through before the project starts.

When deciding what type of managerial structure to use, you should also consider defining the roles of your project team members. Obviously each team member needs to know what his or her role is in the project. Additionally, you should be careful to specifically address each member's responsibilities and how they will be judged for their successes or failures during the project. The final result of this step will be to have a list of tasks, for each task a list of resources (and perhaps a designation of who's responsible for managing/completing that task), and for each resource a description of their roles and responsibilities on that task.

Assuming that you've ironed out the organizational issues between your project and the business, and you've settled on an organizational structure for your project team, you should have an understanding of who's in charge of what and who reports to whom. It is important that you not try and micro-manage the efforts of your project resources. Always keep in mind that there is more than one way to do something, so resist the urge to force changes just because you would have done it somewhat differently (unless of course results are compromised).

The next thing you should do is outline and implement how you are going to monitor the project. You need to decide at this point what people have an interest in your project. Depending on who these people are, you may need to provide regular feedback and reporting to them.  There are quite a few groups that may contain people interested in your project. These groups might be employed within your company, or they may work outside your company. Also depending on your particular project, it could take quite a bit of effort to identify all of the "right" people. In this case "right" really means those people who are important enough that if you don't add them, you may have to make up lost ground when you finally do add them, which could delay your project. This leads to the next phase of identification, differentiate and label the type of persons on your interest list. At the minimum you want to distinguish between people with power to make decisions that can force changes to your project and people who don't have that power. Also identify individuals who are actually working with you on the project. These two lists should leave an everyone else category. You can further sibdivide and refine your labels, but the three categories discussed are the minimum necessary.

Once you've decided who will receive information about the status of the project, you need to decide what information you need to provide.

F. Reporting. (top)

Reporting is probably one of the most important activities you will (or that will be) accomplished during the course of the project. The major categories you will be tracking are: the project schedules, resource consumption, and budget activities. To actually monitor these things you need to collect the information. There are several different ways to collect necessary information: electronic, where team members with access to computerized systems input status information directly into the system; paperwork; inspections; interviews; and meetings. You can, of course, mix and match these. Electronic input is probably the most convenient during the progress of the project, but may take some effort to implement because team members must be trained to use the system and must be disciplined enough to actually use the system. You must also decide upon how often information must be input. This will depend on stakeholder expectations as well as the duration of most activities. Finally, you must decide upon a distribution mechanism. This could be electronic, paper, face-to-face, etc.

Once you have decided upon how to get information, how often to get it and how to distribute it, you need to decide what to report. One of the first things you will want to do is generate a "baseline" for your project. A baseline is simply what you expect will happen over the course of the project when you start the project. Most of your reports will be a comparison of where you currently are versus where you thought you'd be. Some information you might consider collecting includes the task, the person responsible for completion of the task, the baseline start and end dates, the current projected start and end dates, the actual start and end dates or project timing status (such as percent complete), whether or not the task is a critical task, and comments on the task. You should also collect information on how many resources have been expended on each task (hours or other units). Finally, you must put together financial data. We also repeat that all of the data you collect should be compared to the project projections in order to gauge how the project is moving along. These comparisons should allow you to pinpoint any deviations that may be cause of concern.

If you identify a task, or tasks, that appear to be falling behind schedule, or coming over budget, you will probably need to take corrective action of some sort.

G. Changes during the course of the project. (top)

Once you identify a "problem" task, you will need to decide whether or not you need to take corrective action and, if so, what action. The action you take will depend on why the problem has occurred and how serious is the problem. If you believe the problem is unique, see if you can make some minor adjustments to get back on schedule. The need for a correction can be something you observe, or it can come from within the project members. In either event, you need to have a process in place that evaluates the change, documents the change, and implements the change. If you decide that you must make a change, you also need to be very detailed about what impacts on the overall project the change will have. This includes evaluating the impact of changes on other tasks individually. The nature of a project invites the "ripple effect" when change occurs.

We also need to discuss a different, but realted topic - risk. "Risk" involves a potential occurrence that, if it happens, will negatively impact your project. Every project has risk because projections involve uncertainty. Risk can be higher for several reasons: you or your team are relatively inexperienced, the longer the project lasts, and the less skilled your team members are, or the more recent the technology is involved with the project.

The first thing you need to do is identify potential risks within your project. Look at the project tasks and their descriptions and try and list things that could go wrong. For example, say one task is to format a document - and it's a critical task. Joe will be doing the formatting. A risk is that Joe could get sick, or be otherwise unavailable when the document is to be formatted. Make a list of the most likely risks and identify them as internal risks or external risks, and note just how the risk most likely risks would impact yourproject. Next, estimate how likely the risk is to occur. The final piece of information you will need to estimate is what the impact will be on your project. Make sure the estimates of these consequences are quantified and relate them to the overall project, not just the task involved.

You now have the opportunity to plan a risk response scenario. You might choose to take actions that decrease the likelihood the risk will occur. You could also plan a resonse should the risk occur. Or, you may choose to seek indemnification for the risk - insurance is a good example.  If the likelihood of the risk occurring is small, or the consequence low, you might decide to simply ignore it. Whatever happens, for the risks which you have identified, you now have a response documented. What happens if an undocumented risk happens? You will have to develop a work around, which is what we discussed above concerning problem tasks.

(top)