How To Manage A Project (Project Management)

How to Manage a Project

The way to manage a project
Table of Context
Serial no. 01. 02. Introduction The Way of Managing a Project 2.1. Define the Scope 2.2. Determine Available Recourses 2.3. Check the Timeline 2.4. Assemble Our Project Team 2.5. List the Big Steps 2.6. List the smaller steps 2.7. Develop a Preliminary Plan 2.8. Baseline Plan 2.9. Request Project Adjustment 2.10. Work With Plan, But Dont Die For It 2.11. Monitoring Team Progress 2.12. Document Everything 2.13. Keep Everyone Informed 03. 04. Conclusion Reference Contexts Page no.
01 - 04 04 - 58 04 - 11 12- 16 16 - 20 20 - 28 28 - 30 31 - 34 34 - 37 38 - 40 41 - 42 42 - 45 45 - 47 47 - 53 53 - 58 58 59
How to Manage a Project 01. Introduction:

Project management is the application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder needs and expectations from a project. Meeting or exceeding stakeholder needs and expectations invariably involves balancing competing demands among: Scope, time, cost and quantity. Stakeholders with different needs and expectations. Identified requirements (needs) and unidentified requirements (expectations). The term project management is sometimes used to describe an organizational approach to the management of ongoing operations. The purpose of project management is to foresee or predict as many of the dangers and problems as possible and to plan, organize and control activities so that the project is completed as successfully as possible in spite of all the risks. This process starts before any resources are committed, and must continue until all work is finished. The aim is for the final result to satisfy the project sponsor or purchaser, within the promised timescale and without using more money and other resources than those originally set aside or budgeted. To ensure the project runs smoothly and successfully, the following areas required careful management namely: Integration Management Scope Management Time Management Cost Management Quality Management Human Resource Management Communication Management Risk Management Procurement Management

1.1. Background of Project Management In this brief history of project management I chart all the major developments and events in the discipline as far back as there are records. Although there has been some form of project management since early civilization, project management in the modern sense began in the 1950s. We have come a long way since then and recognition of how important the profession is has helped it develop, and will continue to push its development over the next decade. The Evolution of Project Management The importance of project management is an important topic because all organizations, be they small or large, at one time or other, are involved in implementing new undertakings. These undertakings may be diverse, such as, the development of a new product or service; the establishment of a new production line in a manufacturing enterprise; a public relations promotion campaign; or a major building programme. Whilst the 1980's were about quality and the 1990's were all about globalization, the 2000's are about velocity. The Evolution of Project Management - Part 2 As a discipline project management developed from different fields of application including construction, engineering, telecommunications, and defense. The 1950s marked the beginning of the modern project management era. Prior to the 1950s, projects were managed on an adhoc basis using mostly Gantt charts, or with informal techniques and tools. This article looks at four periods in the development of modern project management. How Project Management Developed Could the Crusades have been launched and the soldiers armed and fed without effective project management? Could the Great Wall have been built with ingenious natural materials and a team of millions over a span of a thousand years without project management? It is possible to say that the concept of project management has been around since the beginning of history. It has enabled leaders to plan bold and massive projects and manage funding, materials and labor within a designated time frame. What leaders from the distant past managed to accomplish is amazing and without the project management tools available today. The History of PRINCE2 It's true to say the public sector has hardly covered itself in glory with their ability to deliver projects on time, within budget and scope and to the right quality. PROMPTII, PRINCE and PRINCE2 were all introduced to address the common causes of project failure.
1.2. What is Project Management? More specifically, what is a project? Its a temporary group activity designed to produce a unique product, service or result.

A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. And a project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal. So a project team often includes people who dont usually work together sometimes from different organizations and across multiple geographies. The development of software for an improved business process, the construction of a building or bridge, the relief effort after a natural disaster, the expansion of sales into a new geographic market all are projects. And all must be expertly managed to deliver the on-time, on-budget results, learning and integration that organizations need. Project management, then, is the application of knowledge, skills and techniques to execute projects effectively and efficiently. Its a strategic competency for organizations, enabling them to tie project results to business goals and thus, better compete in their markets. It has always been practiced informally, but began to emerge as a distinct profession in the mid20th century. PMIs A Guide to the Project Management Body of Knowledge (PMBOK Guide) identifies its recurring elements: Project management processes fall into five groups: Initiating

Planning Executing Monitoring and Controlling Closing
Figure: Project management process

Project management knowledge draws on nine areas: Integration Cost Human resources Scope Quality Communications Time Procurement Risk management
All management is concerned with these, of course. But project management brings a unique focus shaped by the goals, resources and schedule of each project. The value of that focus is proved by the rapid, worldwide growth of project management: as a recognized and strategic organizational competence as a subject for training and education as a career path
02. The Way of Managing a Project
2.1. Define the Scope

When it comes to project planning, defining the project scope is the most critical step. In case if a manager start the project without knowing what he or she are supposed to be delivering at the end to the client, and what the boundaries of the project, there is a little chance for you his or her to success. In most of the instances, he/she actually do not have any chance to success with this unorganized approach. Scope involves getting information required to start a project, and the features the product would have that would meet its stakeholders requirements. Project Scope "The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.

There are two places that scope is defined on a project. High-level scope is defined in a project charter. Low-level scope is defined in a business requirements document. High-level scope consists of two main components. 1. Deliverables. If a manager cant remember anything else about scope, list a project deliverables. Defining the deliverables goes a long way toward defining the overall scope of the project. 2. Boundaries. Manager should also try to define the boundaries of his project. Boundary statements help to separate the things that are applicable to his project from those areas that are out of scope. Examples of boundary statements include:

This project will affect BD operations only. All other locations are out of scope. We will deliver our solution to the Finance and Legal departments. All other departments are out of scope.
Think of project scope as a box. High-level scope defines the sides of the box and separates what is relevant to a project from that which is irrelevant. Once the project starts, however, manager generally do not have a lot of requests to change boundaries and deliverables. Most of the scope change requests the manager receive are changes to the business requirements. Business requirements help define the detailed scope. The project deliverables are used to define high-level scope. Business requirements describe the details of the deliverables. If scope is a box, then manager requirements are what fill in the inside of the box. There are two types of requirements. They are:
Product requirements (features). Product requirements describe the characteristics of the deliverables. If the manager was building a bridge, for instance, most of the requirements would be product based. These might include the number of cars the bridge would hold, the strength of the steel, the water level it needs to span, the color of the bridge, etc. Process requirements (functions). Process requirements describe how people interact with a product and how a product interacts with other products. For example, when he discusses how data gets moved and how business transactions flow from one point to another, he is describing process requirements. If manager need to describe the requirements for billing transactions, most of the requirements could end up being process oriented. This would include how billing transactions move from orders to invoicing to accounts receivable. They can describe at what points people look up a status, how people manually update an invoice and what people should do if accounts are out of balance.

If the manager remembers how these pieces fit together, hell have an easier time defining scope for his project in the future. High-level scope is defined in his charter and consists of boundary statements and deliverables. Low-level scope is defined by his business requirements. These two components together make up the entire scope definition for his project. Scope is usually defined by:

Project Business Need Project Goals Product Description Project Customer, Project Sponsor, Project Manager Project in Scope, Out of Scope Project Critical Success Factors Project Assumptions Project Constraints Project Deliverables Project objectives Tasks Resources Budget Schedule
Who is Involved
Project Manager Project Sponsor Project Stakeholders Customers
It is not uncommon for the project scope document to also list specific items that are not part of the project scope and thus are excluded from the work to be delivered. For example, a project to build a house might stipulate that obtaining environmental permits is to be done by the owner and is outside the project scope of the contractor building the house.
Which way to Define Scope

There are numerous ways to define. Ideally several ways should be used. Each looks at the situation from a different perspective and will elicit different information. We look at three main ways in this paper. They are: Define Deliverables Define Functionality and Data Define Technical Structure

Define Deliverables
One method to focus people on the scope is to define the internal and external deliverables. External deliverables are things the project delivers to the users e.g. screens and reports. Users typically think of a system in these terms. It also includes any hardware or software required by the users or the project team. Internal deliverables are things the project generates internally e.g. Project Charter, Business Requirement Specification etc. It is likely that the users will not be absolutely clear on all the deliverables. In this situation you can make generic assumptions. For example, you might not know exactly what reports are required but you allow for 12 unspecified reports. Once the external deliverables are defined, the Project Manager can define the internal deliverables.
Example External Deliverables:

Name License Detail Screen. Company Summary Screen Description Screen to enter and view license details Screen to view all licenses issued by a particular company. Facility to drill down to License Detail Screen. Report listing all licenses due in the next period. Facility to select a period e.g. 1 week, 4 weeks, quarter Allow for 5 unspecified reports Server to run the application
License Due Report
5 Reports Server Etc.
Example Internal Deliverables:

Name Project Charter Description Document identifying how the project will be managed Document identifying the requirements for the project Status reports to be issued weekly Three prototypes will be allowed for in the development.
Business Requirement Specification Weekly Reports Prototypes x 3
Etc.

Define the Functionality
Another technique is to define the functionality. This should not be either a long or detailed process. Typically, depending on project size, the exercise can be completed in a one hour to half-day workshop. A good technique is to use a functional decomposition. If using a spreadsheet and a projector, a scribe can create the scope as it is discussed. Remember to start all functionality with a verb. It is useful to do the functional decomposition in conjunction with a data definition. If this is not possible, once the scope is discussed, it will become reasonably clear what data is required. The Project Manager can determine if there are any situations that need to be clarified with the users, and finalize the scope definition. If for example, in defining the functionality it becomes evident that considerable information will need to be transferred from a legacy system, which is known to be inaccurate, data cleansing can be factored into the scope. Example Functional Decomposition 1.0 Capture License details 1.1 Set up companies 1.2 Set up products 1.3 Create licenses 1.4 Modify licenses 1.5 Delete licenses 2.0 Generate payments 2.1 Create payment report 2.2 Authorize payments 2.3 Notify accounts Etc.

It can also be defined as a diagram:
Customer Management
Add Customer
Delete Customer
Modify Customer
Inquire on Customer
Figure: define the functionality Defining the Data

This approach is similar to functionality, and should be used in conjunction with functionality. The process is likely to capture what users expect to see in a system. The intention is not to make the business users, data modelers. The intention is to get the business users to verbalize their requirements for information in a structured manner. Ask the users what are the people, places and thing they want to keep track of. In this case, the focus is on nouns. This approach will not capture data that may be required to technically make the system work. For example, it will not capture things like transaction log files, archive files, SQL script files etc. Post workshop, the Project Manager will need to sit with a data modeler to sort out what else is required. The hardest part is to stop doing a data model. Keep the focus on where the data is to come from, and identify what is new, where the interfaces are likely to be, is existing data suitable, is the data currently captured etc.
10

Data Definition Example:
Name Companies Description Details of the company including address, overseas offices, and up to ten contacts Licenses for all software and hardware used in the organization. Include contracts, correspondence, quotes and any other related documents. Does not include manuals Dates the license is due for renewal and the cost of the renewal.
Licenses
Renewal dates Etc.
Technical Structure Definition

This technique can be useful in defining scope where the project is focused on infrastructure. It can also be useful in a situation where an existing system is being modified. The output can be either a table, or a diagram. A table might just list the components to be modified and the modification. The structure diagram might identify the whole system and highlight which components are being modified and how they are being modified. It may also be appropriate to
indicate the purpose of each component; however it will probably be vague at this stage of development.
Example:
The outputs HTML module takes information retrieved from the database and inserts it into an .asp document for output to the server. It also updates a transaction log with the database information and time of the output. If an error occurs in retrieving data from the database, an error log is updated and an error page sent to the server.
Example Technical Structure Table

Component Subsystem1 Description Handles all customers processing and interfaces to CMS (Customer Management System). Carries out inquiries on billing systems (2) and combines data into common format. Sorts data by date of payment.
Subsystem2data
Etc.
11

Understand the Project Objectives
In order to define the scope of a project, it is necessary to first establish the project objectives. The objective of a project may be to produce a new product, create a new service to provide within the organization, or develop a new bit of software. There are any number of objectives that could be central to a given project - and it is the role of the project manager to see that their team or contractors deliver a result that meets the specified functions and features. Defining a projects scope helps establish a common understanding for all project stakeholders. It is the foundation on which the schedule, budget and staffing plans are built. Scope also serves as the basis for future project decisions. The documented scope helps address scope creep by making changes obvious. Scope management involves ensuring that all works are included into the project with what the client wants and items that are specified in the specification.
Scope Creep:
Scope creep is something common with every project. This refers to the incremental expansion of the project scope. Most of the time, the client may come back to the service provider during the project execution and add more requirements. Most of such requirements haven't been in the initial requirements. As a result, change requests need to be raised in order to cover the increasing costs of the services provider. Due to business cope creep, there can be technological scope creep as well. The project team may require new technologies in order to address some of the new requirements in the scope. In such instances, the services provider may want to work with the client closely and make necessary logistic and financial arrangements. Project scope definition is the most important factor when it comes to project requirements. It is vital for services providers to define the scope of the project in order to successfully enter into an agreement with the client. In addition to this, the scope of the project gives an idea to the services provider about the estimated cost of the project. Therefore, services provider's profit margins are wholly dependent on the accuracy of the project scope definition.
12
How to Manage a Project 2.2. Determine Available Recourses

What are Resources? Resources are commonly thought of as sources of supply or support, such as money, people, materials, technology, and space. For a projects, more specific resources may include system developers, project managers, system analysts, stakeholders, development environments and information. Resources are absolutely essential for the project management team and or the project management team leader to have at their disposal if they hope to be able to successfully complete a project and attain a level ofresults that are considered satisfactory. However, in order to assure that the project management team and or the project management team leader are able to assess properly what exactly resources are. First of all, resources can consist of any and all groups or individual human staffing resources. In this instance, resources are specifically the people who can be allocated to the respective project or to the particular work element within the project, and whose time can be allocated accordingly. Resources can, however, also refer to any number of inanimate objects that may be utilized by the project management team and or the project management team leader in the management of the project, such as supplies, services, commodities, and budgets. Types of Resources: There are two primary types of resources used in a project namely: Human Resources, Capital Resources. Human Resources: Human resources are personnel pool available to an organization. The most important resources in any organization its human resources. Appropriate human resources assure an organization that the right number and kind of people are available at the right time and place so that organizational needs can be met. Human Resources include all project stakeholders, such as customers, project team members, support staff, project suppliers and end users. Human Resource Management is the strategic function performed in an organization that facilitates the most effective use of people (employees) to achieve organizational and individual goals. The person that manages Human resources is called Human Resource Manager or Personnel Manager.
13

The Role of a Human Resource Manager is acquiring Human Resources Maintaining Human Resources. HUMAN RESOURCE PLANNING The term human resource planning refers specifically to a project management process that involves the careful and deliberate identification, categorization, and ultimately, documentation of the entirety of all project roles assigned to all individual members of the project work team. Included among this documentation process is a careful delineation of all of the individual project team members personal responsibilities in regards to management of the project, as well as all the specific reporting relationships among all members of the project team. One additional essential component of the project management process of human resource planning is a careful and thoroughly executed encapsulation of all members of the project team through a complete project staffing management plan. This can be done through the use of either a formally written document, which can include a detailed graphically formatted chart, or it can be in the form of a less formalized document of sorts. Capital Resources: Capital Resources can be defined as the tools and infrastructure used to produce other goods and services. While the range of assets that can be considered to be a capital resource is very broad, it is important to note that not all assets are capital resources. There are a few basic qualifications that govern what assets can properly be referred to as a capital resource. One of the basic criteria for an asset to be considered a capital resource relates to the longterm use of the asset in the production of goods and services. In general a capital resource will be anticipated to aid in the creation of products for an extended period of time. The management of capital resources is particularly important when considering opportunity costs. Opportunity costs are a measure of the alternative opportunities forgone in the chose of one good or activity over others. Managing Resources Efficient and effective use of resources can often make or break a project. Because resources are limited some hard to be obtain, expensive or both. The allocation of resources can have a major influence on project schedules. For example, limited programmers effects time, cost, quality, risk management.
14

ACTIVITY RESOURCE ESTIMATING [PROCESS] Activity resource estimating is a process in which the project team carefully compiles a thorough listing of the resources that will be needed in completing a project. There are six inputs that are to be used in the process of activity resource estimating. Those six inputs are the activity list, the activity attributes, the organizational process assets, the enterprise environmental factors, and project management plan, and the resource availability. There are a number of tools that can also be utilized in most effectively estimating the required activity resources. Those tools include expert judgment, a complete alternatives analysis, the use of published estimating data, project management software, and the use of bottom-up estimating. The resulting outputs from this process include activity resource requirements; activity attributes updates, requested changes, a resource breakdown structure, and the development of aresource calendar. The successful utilization of activity resource estimates will help assure that enough resources are acquired without waste and excessive expenditure. The goal of activity resource estimating is to estimate the resources needed for each activity so they can be deployed in the most effective manner. Activity sequencing Resource availability Completed project schedule with durations Resource needs Managing resources. Resource Estimation Techniques One of the primary tools of project resource estimating is expert judgement. Expert judgement is estimation based on the experience of one or more experts on the particular activity or project. Another source of hard data is published estimating data hard data from specific activities carried out on previous projects that may be used to more accurately estimate resource needs. When estimating activity resources, it is often advisable to conduct some form of alternatives analysis an estimating technical in which tradeoff between the time needed the resources invested and the desired quality of the final deliverable are examined. Also bottom up estimating is a technique applied when the resource needs of an activity cannot be easily estimated. The primary output of the activity resource estimating process is a detailed listing of the resource requirements. Resource Estimation Outputs Activity resource requirements is a very detailed listing of the resource requirements for the individual activities. Resource breakdown structure is a hierarchical, graphical representation of all needed resources ordered by type or category.
15

Resource calendar is a specific type of project calendar that is used to track the hours when certain resources are available. Activity duration estimation is the process of estimating the duration of the project activities using both project scope and resource information. Critical path analysis: Critical path is to established have quickly a project can be completed given the tasks, durations and dependencies in network diagram. Critical path method uses the 2 concepts Free float: the time an activity can be delayed without affecting the immediately following activity Total float: the time an activity can be delayed without affecting the overall completion of project Critical chain method the longest path through a network diagram, considering both task dependencies and resource dependencies and when using the critical chain method, the critical path is first identifies, independent of resource availability. When using any of these techniques, a project manager should always monitor project and resource calendars (times). Matrix management Matrix management is a type of organizational management in which people with similar skills are pooled for work assignments. For example, all engineers may be in one engineering department and report to an engineering manager, but these same engineers may be assigned to different projects and report to a different engineering manager or a project manager while working on that project. Therefore, each engineer may have to work under several managers to get their job done. A style of management where an individual has two reporting superiors (bosses) - one functional and one operational. This is commonly seen in project management where an engineer, for example, reports to the chief engineer functionally, but reports to the project manager on operational project issues. Matrix management also is common in branch offices. The accountant in the Tokyo office reports functionally to the Vice President of Accounting in headquarters in London, but reports operationally to the Regional Manager in charge of the Tokyo office. Generally the functional reporting relationship is stronger, because the functional manager controls the individual's compensation and evaluations. Matrix management also known as dotted line responsibility.
16

Examples: For a matrix management style of organization to be effective, the functional and operational managers must have equal weight in controlling the individuals in their matrix.
Figure: Matrix Management
2.3. Check the Timeline

Timeline is used for project management. In these cases, timelines are used to help team members to know what milestones need to be achieved and under what time schedule. For example: in the case of establishing a project timeline in the implementation phase of the life cycle of a computer system. Time scale Timelines can take use any time scale, depending on the subject and data. Most timelines use a linear scale, where a unit of distance is equal to a set amount of time. This time scale is dependent on the events in the timeline. A timeline of evolution can be over millions of years, whereas a timeline for the day of the September 11 attacks can take place over minutes. While most timelines use a linear timescale, for very large or small timespans, logarithmic timelines use a logarithmic scale to depict time.
17

Types of timelines Text timelines are timelines that which are labeled as text Number timelines are timelines where the labels are numbers, commonly are line graphs There are many methods of visualizations for timelines. Historically, timelines were static images, and generally drawn or printed on paper. Timelines relied heavily on graphic design, and the ability of the artist to visualize the data. Timelines, no longer constrained by previous space and functional limitations, are now digital and interactive, generally created with computer software. DURATION The term duration refers, in a big picture sense, to the total and complete amount of time that will pass from the moment that a project is initiated until the very last moment in which the final deliverable is provided to the buyer and those final deliverables are approved. The duration, more specifically, represents the total and complete sum total of work periods (not including any non-working periods which can include holidays or other scheduled time of) that is required to complete a particular schedule activity or specific component of the work breakdown structure. Duration is often expressed in terms of work days or work weeks and often times is confused with the similar but slightly different term elapsed time. Duration can be directly contrasted with the term effort. Original duration is one of the most critical elements of effective and comprehensive project management, as it is a truly valid representation of the length of time that it was originally assumed it would take from the onset to the conclusion of the project. To be more specific, in terms of the life cycle of the project, the original refers specifically to the activity duration that was assigned at the onset of activity only. This original duration is a static element, and is not a living mark. It is not in any way, shape, or form updated as the project advances and there are some very particular reasons why it is a good idea for it to not change. Primarily, it is helpful for it to remain in its original state because it allows the project manager and project management team to view it in comparison to the actual duration and to the remaining duration when making an assessment of the progress to date. The term actual duration can refer to a couple of different things depending on usage and context. In one usage, the term actual duration can refer to the exact amount of time between the date on which the actual start date of a schedule activity falls and the date on which the project schedules data date falls (assuming the schedule activity is still in progress). Alternately, in the event that the schedule activity has concluded, the term actual duration can
18

refer to the time between the actual start date of the schedule activity and the actual finish date. The actual duration can be measured in any standard calendar units, including days, weeks, months, years, etc., and the most appropriate should be chosen given the situation. The actual duration may result in findings very similar to the durations estimated at the start of the project, or due to factors that were unforeseen at the time (delays, financial hang-ups, etc.), the actual duration may vary wildly from the initial projections. A data date refers specifically to the date in the life of an ongoing project upon and through which the previously defined system of reporting for that given project is to provide the actual status of that project and the accomplishments attained in regards to that project to date. In some previously defined systems of project reporting, the reporting of status information is given in terms of past data, focusing primarily on items accomplished to date with specific delineations of items. This can be thought of in terms of items checked off a list. In some previously defined systems of project reporting, the reporting of status information is given in terms of future data, meaning, a list of items that are still remaining, and/or, to be accomplished from this point in time. Date can also be referred to as as-of-date and time-now date. Project management must always keep in mind the predicted completion of the task. Once the work has ended, the project has reached its actual finish date. This can be different from when the job is ruled as finished. That is due to the incidence of certain tasks being labeled as finished when a large majority of the work has been done, but the job still needs some work. The actual finish date can differ from the projected completion date. Unanticipated events and other delays can contribute to that difference. Projects with environmental factors often have several days built into the time table to allow for weather related delays in the work. Project management can assist in bringing the predicted and actual finish date closer together by minimizing external forces and events which might slow work. Those working in project management might consider offering some incentive to their employees for completing the job with an earlier actual finish date than the predicted date. This can encourage faster, more efficient work among the employees who would like to get work done on the task as soon as possible for their own benefit and that of the company. In project management, accurate reporting on schedule progress entails documentation of the remaining duration of each schedule activity. In schedule reporting, this term is used when referring to work that is currently in progress. The time remaining for an activity is calculated from the date that the report is created. The remaining duration is defined as the number of calendar units between the date the report is generated and the current (expected) finish dates for the activities in question. This information is often displayed as a bar graph that also shows the actual start dates of the schedule activities. This type of project management snapshot
19

report makes it possible to visually assess the percentage of work completed and the estimated percentage remaining. This information is often helpful for ongoing human resource planning. It can be used to calculate an estimate of how many labor hours are required for completion of a current schedule activity. Calendar units are used rather than days to provide the greatest level of accuracy in remaining duration reports. A calendar unit may represent a workday, a shift, a work hour, or any other time unit that is relevant to the nature of the project. This includes only units during which work is actually performed and not times when the schedule activities are idle (weekends, nights, holidays, etc) unless otherwise specified. This means it is important not to confuse the number of units remaining with the number of actual days. For example, if 10 calendar units are left in the duration of an activity, this might represent 80 total hours of work done between Monday and Friday on two consecutive weeks. So, the actual date of completion might be 14 days in the future rather than 10 days. ACTIVITY DURATION Activity duration is a noun that represents the specific quantity of time that exists between the designated start time and end time of a scheduled activity. For further elaboration on this definition, please see the definitions for actual duration, original duration, and remaining duration. Activity duration should be carefully measured from the start date to the end date and can be calculated in whatever calendar units are appropriate given the anticipated timeframe of the project, such as days, weeks, months, etc. The activity duration can be established when a project is conceived, or it can be established when a project is kicked off, and is typically fluid in nature, and able to be modified if the situation merits and with the agreement of all parties. Furthermore, the sum total of the activity duration can also be broken up into smaller parts in the establishment of project milestones, points at which either the current state of the project will be assessed, or potentially sum or all deliverables will be submitted in either final or draft form. ACTIVITY DURATION ESTIMATING Activity duration estimating represents the act of quantifying the amount of time that it is anticipated the activity will take to complete. This phase of the project, that which consists of the estimating of the amount of time needed to complete all individual schedule activities, typically and traditionally takes place before a project is kicked off, during the conception phase, however, it is possible for the actual activity duration estimating period to take place later, perhaps close to or even slightly after the project has officially kicked off, however, even in those cases a draft or preliminary estimation has typically been made. Estimations can be made in any calendar unit that seems appropriate, such as months, weeks, days, etc., the entirety of the activity duration estimate can be further broken down into subparts or
20

milestones at which certain elements, or deliverables, of the activity are to have been completed in final or draft form. MILESTONE Throughout the entire life cycle of a project, there are going to be a number of natural time gradients that exists, and are more than likely to be defined by the eventual and natural ebbing and flowing of the project workload and the momentum of the teams performance and the business of the schedule. However, it is typically helpful in attempting to assure that the project is moving effectively as well as to allow points in time for the project team to pause and look back on what has been accomplished to date as well as what may need to be changed in the future for the project team leader with or without the help of the project team to establish a number or series of project milestones. These milestones can occur at any point throughout the project and specifically refer to any significant or substantive point, time, or event in the life cycle of the project. These milestones typically refer to points at which large schedule events or series of events have been completed, and a new phase ort phases are set to begin.
2.4. Assemble Our Project Team

A project team is a group that works together to execute the tasks necessary to meet customer requirements. Before a project team meets for the first time, before they start "forming, storming, norming, or performing," or maybe even before they know they will be working together, the project manager begins laying the foundation for effective teamwork. Pulling together the right project team is both a challenge and a precursor to successfully achieving all subsequent project steps. A common challenge is that the best people for the team are typically the people with the least availability (there's a correlation here). Sacrificing the project team by accepting people that are available, as opposed to people that are best suited for the role, is an initial mistake that many times will doom the implementation project. So who should be on the implementation team? The roles and size of the project team will vary based on the scope of the implementation, the number of users, the number of physical locations, the level of sophistication and the resistance to change which may be encountered. We can assemble our project team by using following diagram_
21
Figure: the way of preparing an effective team.
22

PROJECT TEAM The idea of the project team is an all-encompassing concept that details and explicitly documents the entire grouping of individuals that may factor into the ultimate staffing of a project from start to finish. The project team may be determined by any and all members of the financially responsible organization. The financially responsible person of persons who typically will be responsible for determining the project team will often times only directly be involved in selecting the person who will serve as the project team manager and or the project team leader. And then, as part of that newly anointed project team manager or project team leaders initial round of responsibilities, which project team manager and or project team leader may be charged with the task of filling out the remaining positions available within the project team as a whole. This can include selecting specific team members with the specific tasks in mind, or rather, merely selecting a balance of team members with the idea of assigning specific tasks later. For an example of how a medical group redesigned its diabetes care system by creating a team that involved not only physicians and clinical staff, but also other staff and patients.
Figure: project team
23

Goals Setting We must set clear achievable goals. We must set them for our team as a whole and must set them for the individuals within our team. They must be unambiguous and they must be mutually attainable. That is to say, no one individual's goal should in any way conflict with that of another individual. In fact we want it to be in everybody's interest that each individual achieves his own goal. Design the goals accordingly. We must try to build a team that works together with common aims, all working towards the same final goal. Achievable Goals Make use of our goals to build team spirit and enthusiasm. Do this by setting small, easilyattainable goals early on in your project while your team is still bedding-in and settling down. Make them worthwhile goals, but goals that you are almost certain can be reached. In this way our team will notch up some early successes, which will certainly boost morale and establish a sense of pride in the achievement. Later goals that you set can (and should) be more taxing and testing, but the early successes will do wonders for the spirit of the team. This spirit will endure long into the future as the going gets tougher. Communication It is almost impossible to exaggerate the importance of communication within any organization, and in particular within a project team. Make it our duty to ensure that everyone within our team knows what is going on. Make sure that everyone knows of outside events that will affect the team. Make sure that everyone knows their own goals and objectives and those of the team as a whole. Make sure they know the objectives of those interfacing to them and of any potential conflicts. Make sure that a problem or a delay in one area is immediately communicated to those whom it may affect. Encourage and foster co-operation, not competition. Make sure it is in no-one's interest to keep information to them. Communication will come naturally if it is in everyone's own interest - and this will be the case if you have earlier ensured that we all have common mutually interdependent goals. These guidelines on their own are certainly not enough to guarantee a fully functional and successful team, but following them will go a long way towards creating one. On the other hand, if you don't follow them our chances of success will be minimal. Organizing Organizational planning identifies, documents, and assigns project roles, responsibilities, and reporting relationships. Before the project begins, all role and responsibilities should be designated. This will cut down on any confusion after the project starts. Each team member will know what is expected of him or her and will be able to follow through on the assigned tasks.
24

Having a staff development plan and an organizational chart will also decrease uncertainty and conflict. A staff development plan describes how and when human resources will be brought onto and taken off the project team. An organizational chart is a graphical way to breakdown the project reporting relationship. It diagrams who is to report to whom. There will not be any question as to the chain of command with a detailed organizational chart. Good organizational planning also includes any supporting documents needed to outline each job title and description or any training needs. Acquisition Staff acquisition is the process of getting the human resources needed assigned to and working on the project. Choosing the correct people for a project is almost as important as the project itself. Without a knowledgeable team, the project will be much more difficult. Some things to consider when picking our team are previous experience, personal interests, personal characteristics, availability, and competencies and proficiency. Our resources for finding team members are endless. They may come from negotiations with managers and other project teams, pre-assignment from another project, or even from outside the organization. We will also need to determine whether each team member will be working on the project full or part time. Thinking ahead of the ideal team members will save our valuable time later. Team Performance Development Team development includes developing individual and group competencies to enhance project performance. By coming together as a true team, the project will be more successful. Team development can be achieved a variety of different ways. Team building activities General management skills Reward and recognition systems Collocation or frequent face-to-face meetings Training Significant improvements in team morale will cause an increase in team mentality. Other improvements that will be seen include performance improvements, improvements in individual skills, improvements in team behaviors, and improvements in either individual or team competencies. If there has been proper team development, our project will run with the epitome of efficiency and quality. We will see performance improvements, improvements in individual skills, improvements in team behaviors, as well as improvements in either individual or team competencies. ACQUIRE PROJECT TEAM The acquire project team process involves the process of obtaining the specific people needed to accomplish all phases of the given project. Ultimately the team members would all bring specific qualifications and capabilities to the project team, although when workloads require so, duplicity may be required. Often times, the ultimate selection of a project team is made by the
25

project management team. In addition to toe goal of diversifying the team and acquiring team members that bring differing assets to the team, a number of other factors should be considered when choosing the team members, Those factors include a series of enterprise environmental factors (such as work experience, availability, and cost among others), derivation of clear and concise project organization charts, and formulation of a thorough staffing management plan. Once the team has been properly staffed, the next steps (or outputs) of the process involve staffing out assignments to the team, determining availability of our resources, and updating your staffing management plan. PROJECT TEAM MEMBERS The concept of the project team members highlights the entire grouping of individuals that may factor into the ultimate staffing of a project from start to finish. The project team may be determined by any and all members of the financially responsible organization. The financially responsible person of persons who typically will be responsible for determining the project team will often times only directly be involved in selecting the person who will serve as the project team manager and or the project team leader. And then, as part of that newly anointed project team manager or project team leaders initial round of responsibilities that project team manager and or project team leader may be charged with the task of filling out the remaining positions available within the project team as a whole. This can include selecting specific team members with the specific tasks in mind, or rather, merely selecting a balance of team members with the idea of assigning specific tasks later. When discussing the responsibilities of various associates involved in project management, team members play a crucial role. Team members will be assigned duties that assist in accomplishing the overall goal of the project. These assigned tasks and duties are important to the overall success of the project and must be done in a timely manner to ensure compliance with the project plans timeline. Team members will be expected to keep project management apprised of their progress. Depending on the needs and organizational structure of the project, team members may be instructed to report directly to the project manager after completing tasks. In other instances, team members may be told to report to another associate involved in the project management and not the project manager directly. The many tasks that the project is comprised of are each important pieces of the whole project. Team members may be asked by project management to work on goals, tasks or milestones only- and have no other duties or responsibilities. Some projects may require team members to perform tasks for the project while still accomplishing their regular assigned duties.
26

Project Team Leadership Leadership of the project team is crucial if the project is to be completed on time, to the required standard and within the overall budget. While managing people is a critical part of our responsibility as a project manager, what is more important is that we actually guide them as they work to help us achieve our objectives. Being an effective project manager means understanding the needs of our team members, the expectations of our stakeholders, and at times, being the intermediary between the two. Be aware of how others contribute to project team relationships Improve personal and project team effectiveness When referring to a group of individuals as the project management team, it is helpful to take a step back and do a more careful review of what exactly the term project management team refers to. And more specifically, of course, who the term project management team refers to. Breaking it down more carefully, you will see that the term project management team is comprised of the individual and unique members of the project team who find them to be directly involved in any or all project management related activities. ON some projects that exist on a smaller scope, it is possible that the project management team may actually not be a distinct and separate unit from the project team but rather may include all project team members of virtually all project team members. Typically the project management team is broken down into some sort of a hierarchal format and that structure is typically headed up by a project management team leader, a term which is often used interchangeably with project manager. MANAGE PROJECT TEAM When a project team is assembled in preparation for a large scale project to get underway, what is absolutely essential up front is to establish and determine the person who will be responsible for managing the project team, as it is essential to have a single voice to speak for and represent the teams ideas, and also control and harness the activities of the team, which improves productivity and cohesion of the team process. Specifically, the concept of manage project team refers to the project management process that involves the actual tracking of the performance of each individual team member, providing any necessary feedback in regards to that performance, resolving any issues that may have arisen in the process to date, as well as coordinating and implementing any changes that may need to take place for the sake of enhancing the performance of the project team from the current point forward.
27

The Importance of Team Working The principle of working together with our team should underpin how we operate. Managing people doesn't just mean acting as overseer, to see that they get their work done satisfactorily. It means involving people throughout the team in a creative role, to ensure that together we are all able to succeed. Involving people on broad issues is motivational. Never underestimate people. Their views can enhance everything: methods, standards, processes and overall effectiveness. Remember, managers are not paid to have all the ideas that are necessary to keep their section working well in a changing world, but they are paid to make sure that there are enough ideas to make things work and go on working. PROBLEMS IN THE PROJECT TEAM Most of the team-work results in the cancellation or a delay of the project because of the disfunctionality of the team and the team leader. However, there are steps that can be taken for the effective team results: Leaders and the team have to follow the right behavior. Leaders have to clearly define roles and expectations right from the beginning. For better communication, individual meetings with team members are very essential. Understanding each other well among team members will help in creating trust more responsibility etc., for solving problems. Every team member needs to commit to the project and the team as well as the desire to improve ones own performance. Leader should set a goal, create follow-up meetings, and communicate that deadlines have to be strictly followed. The leader has to set a mission statement and to develop communication strategies for his team. Young professionals should be included in a team for the better usability of mixture of ideas.
A problem in the team project should be solved through the way of conducting productive meetings and discussions of the problem by all team members in order to find out the proper solution. Proper commitments and strategies must be applied to the whole team so that it will end up with better team results.
28

REDUCING PROJECT TEAM STRESS When the project management team is trying to meet deadlines to successfully complete a project, there is sure to be a certain amount of stress. Managing stress is crucial since it could affect performance and, ultimately, the success of the project. Believe it or not, not all stress is bad. While negative stress can reduce efficiency and take focus away from the project, positive stress can focus the team on goals and boost productivity. The aim then is to turn any negative stress into positive energy. Certain people or small groups can interject negativity on the whole team. Address these people directly and ask them to improve their attitudes so that the rest of the team can be happier in their work. If they have a legitimate grievance let them know you are listening and deal with the problem. As project manager you should also watch your own mood. If you are stressed, it could be affecting the whole team. Instead, be positive and upbeat letting that rub off on the team. Take time to meet with team members individually and do what you can to boost their morale. With more confidence they are sure to be more productive. Recognize accomplishments with positive feedback and possibly provide bonuses, prizes or awards for excellent work. Also, consider reviewing salaries if performance warrants. Take some time to build positive relationships. Provide a time and place, away from work, and get to know each other. Remember to not talk about work. Finally, hold frequent project management meetings to reinforce collective goals. Be positive so the team will leave energized and focused on completing the project.
2.5. List the Big Steps

Though every project is unique, a manager has learned that every new initiative presents a predictable set of challenges. He doesnt care if he is starting a business, writing a book, or launching a podcast, he has to take at least seven steps to succeed. Write down a goal and a due date. Many people skip this step. Dont. There is something that happens when the project manager write down a goal. Its a way of focusing his intention and clarifying what he wants to accomplish. And be sure to attach a dateno goal is complete without it.
29

Confront his biggest fears. If your goals dont scare you, you arent thinking big enough. Most of the value in goal-setting is the growth that must take place in you to achieve them. Often, this is frightening. In the case of his podcast, he had to confront these fears: I dont have any real experience with audio technology. I am not sure I am smart enough to understand it. I dont really want to spend the money to get decent equipment, especially when I am not confident I will follow-through. I am really not sure I can make the podcast interesting enough. Will anyone really want to listen? Those are just a few of the fears I faced. However, I have learned that courage isnt the absence of fear. It is the willingness to take the next step in spite of the fear. Get the necessary training. One thing I learned from my dad is that its possible to learn how to do almost anything if you are willing to read, take a class, or hire a coach. Not only has someone somewhere in the world figured out what you want to do, but someone has also mastered how to teach it. In the case of podcasting, that person is Cliff Ravenscroft. I listened to numerous episodes of his free podcast, The Podcast Answer Man. I also bought his super helpful courses, including: Get started on the work. Some things can only be learned by doing. Yes, you can read. Yes, you can listen to or watch online training. But at some point, you have to jump in the pool and get wet. In the case of podcasting, I jumped into recording my first podcast. I hated the way I sounded. My compulsive, perfectionist tendency kicked in, and I tried to edit out all the imperfections. It took forever. I almost quit. The only way I figured this out was by creating the workflow, giving it a try, and then reengineering. I am sure I will get better with practice. Trust the process. This is huge. Usually, when I take on something really big, I only have a foggy idea of how to get from point A to point B. I have enough light to take the next step, but that is usually enough. When I take that step, the next thing I need shows up. Not always, but usually. In the case of the podcast, I didnt know what equipment to buy. I asked a few friends, ordered a microphone, shock mount, pop filter, and desk boom from Amazon. I tried it all out, didnt like it, and ended up returning all of it. Example, I had to submit my finished podcast to iTunes. I didnt know how to do this at the beginning of the process. I didnt discover how until two days before I
30

launched. Then I messed it up by submitting the wrong link! Regardless, I kept marching forward, not getting approval until hours before my podcast went live. Go ahead and launch. At some point, you have to ship. So many people keep fiddling with it, hoping to get it perfect. General George Patton once said, A good plan violently executed now is better than a perfect plan executed next week. I could have tweaked my podcast endlessly. Believe me, I was tempted to do so. But I had set a goal to launch by February 15th. I had shared this plan with my teammates. Therefore, I was committed to making it happen. Tweak as you go. The great thing about most projects todayespecially web-related or new media onesis that you can keep fiddling with your project after you ship it. In the case of my podcast, I discovered several items I wanted to change immediately. For example, I initially didnt use a graphic image in the blog post (i.e., show notes). I thought the audio player was enough. I changed my mind and added a graphic image to make it more visually interesting. While launching your project is a one-time event, constant and never-ending improvement is ongoing. But you can never get to the second if you dont do the first. For an example: PRINT WEB For example: Major Pieces (minimum 6 weeks - up to six months) Print Support Symposia/Campus Events and/or collateral Enrollment Management - (Postcard Series, Fliers, View book/Brochures) Alumni Weekend Brochures and Postcards Cabrini Classic Materials Commencement Materials Marketing Materials Catalogs These projects include: large publications or a series of printed pieces, pieces that require strategic planning, custom photoshoots, and may have multiple approvers. For example: Redesigned website section New website section Online photo gallery New Web presence related to specific initiatives (Financial Aid/Giving)
31
How to Manage a Project 2.6. List the smaller steps

Now let's look at a practical approach, grounded in a Project Management Institute -based framework, for planning and executing small projects. Starting a few years ago, our company began using a formal project planning template that has helped us significantly to plan and manage our projects. After we clarified our vision and mission, and decided to become a "projectized" organization (and not just how to teach others how to do that!), a formal planning process and various templates were natural outgrowths. Steps of managing small projects Once you've identified work that should be managed as a project, now it's time to start planning and executing the project. Our method for managing small projects involves five basic steps. The five steps are project: 1. Sanctioning. 2. Scope 3. Scheduling and Estimating. 4. Status Reporting/Executing. 5. Success - Closing the project. 1. Project Sanctioning To be successful, all projects need to be sponsored and supported. The project sponsor owns it, and must approve its deliverables. Without this formal sanctioning of a project, it may be doomed to failure. The number one contributor to project success, according to a recent Standish Group Report (2001), is executive support. User involvement, experienced project managers, clear business objectives, and minimized scope are close behind as factors of successful projects. Executive support for a project is documented through a project charter. A charter sanctions the project, and outlines what the sponsor expects the project to produce. It's meant to be a business document, not a technical one, and is designed to be short. Ideally, the sponsor should create it, but, minimally, they should sign off on it. As frequent project sponsors ourselves, we have found that slowing down long enough to create a charter forces executives to think through the need and vision for a project. Additionally, it often stops many a "good idea" from being delegated as a small project and forces the sponsor to justify the business need for the project. The graveyard of abandoned projects often comes from those good ideas that weren't thought through well enough, and the instigator has gone on to the next "big idea.
32

2. Scope The next step in managing a small project, and a natural follow-on to sanctioning it, is defining the scope. The scope statement defines the projects: business issues and their impact, objectives (what the project should accomplish for the business), and deliverables (including features in and out of scope). In other words, it defines what is "in scope" for the project. The sponsor signs off on this document, too, and commits to it. Sponsors are responsible for and need to make the decisions about the extent of the project, while project managers are responsible for planning the project and reporting against the plan. It's a distinction the authors as project managers have learned the hard way: it's easy for sponsors to abdicate and make project managers responsible for scope decisions, and then blame the PM for expanding the scope and missing deadlines. Another way to think about the scope is to think about it as the project manager's answer to the sponsor's charter. The scope statement interprets the business need and how the project will solve it. If it's it done right, the sponsor can use it to verify if and how their vision will be carried out through the project. We use a simple template for the scope statement and combine it with the rest of the project plan for simplicity.
Figure: Scope of small project 3. Scheduling and Estimating Before starting a project, you also need to estimate how long it will take to accomplish the project objectives. For small projects, we suggest taking each deliverable and breaking it down to determine the tasks needed to produce each one. The resulting list of tasks is called a Work Breakdown Structure (WBS). The WBS helps you plan all the necessary work, and only the necessary work needed to meet the project objectives. It's an essential tool for any size project. Breaking projects into smaller tasks makes it easier to estimate the time needed to perform the work, and it can be rolled up into an overall project estimate.
33

The project schedule guides the flow of work, to ensure things are done in the right order. Tasks for the schedule come from the WBS, and allow sequencing work so that: Tasks will be done in the right sequence, reducing delays, Tasks with no dependencies can be done in parallel with other project work, shortening the schedule The longest sequence of tasks will dictate how long the project will take. 4. Status Reporting/Executing This step is finally where project work begins. By now you've scoped out the project, divided it into deliverables, broken it into tasks, and created a schedule. It's time to work the plan. On larger projects, experts say 90% of a project manager's time is spent communicating. For smaller projects, especially when the project manager is doing some or all of the work, the communication time is obviously much less. But, it is essential to communicate project status as it is executing. We suggest weekly status reports to the sponsor, describing: What has been accomplished since the last report, How much time and money have been spent, Variations from the budget or schedule Any project issues that have arisen.
Figure: Executing 5. Success - Closing the Project As each deliverable from the scope statement gets completed, take the opportunity to celebrate success. Of course, the sponsor should approve each deliverable first. After all deliverables have been approved, the project can be closed out. This step is important because
34

it gives you one last chance to celebrate, and feel good about what the project has accomplished. It's a great morale boost that beats being rewarded by more work immediately! Equally important, closing out a project is the time to do a Lessons Learned session with the project team. A Lessons Learned meeting recaps what went well on the project and what could be improved for the next one. Both are valuable for capturing knowledge acquired during the project that can be built on in the future. The lessons learned can be listed on a close report, which is also useful for summarizing project time, cost, and variances from the budget and schedule.
Figure: Close Project
2.7. Develop a Preliminary Plan

PROJECT MANAGEMENT PLAN The concept of the project management plan is one of the most fundamentally important things that the project management team and the project management team leader needs to know in order to properly and most effectively manage a project from start to finish. Specifically speaking, the project management plan refers to a particular and unique input and output divide that consists of a formal and approved document or set of documents that ultimately and completely defines how exactly the project is executed, managed, monitored, and controlled. The plan in some cases may be very carefully and completely detailed, or in some others, it may be broader stroke, presented in more of a summary style format. It may be composed of one and many more subsidiary management plans, and may also be composed of any number of other planning documents. It is important that the project management plan be determined at an early stage of the project management process.
35
Figure: Planning
This task commences the development of the project plan. The project plan is a dynamic document that is progressively developed as the project matures and information becomes available. This preliminary plan is included within the business case and takes effect when the business case is accepted. The preliminary plan provides direction and control of project activities until a more comprehensive plan can be developed and approved.
Figure: Preliminary Plan
36

The preliminary plan will define: the project background and reason for existence the project objectives and success criteria the project scope and high level work breakdown structure a project schedule detailing key activities and major milestones a project structure for the management of the project including responsibilities, accountabilities and reporting requirements an estimate of costs associated with the management of the project out of scope items, related projects, constraints, urgency and assumptions impacts, both internal and external risks procurement strategy an approach for progressing the project through the remaining phases. Responsibility The project manager is responsible for this task.
A PROJECT PLAN IS MORE THAN A MS PROJECT GANTT CHART A project plan not only outlines the specific goals and timelines for a project, it also breaks down the various tasks needed to accomplish the goal of the project. Project planning is an important part of making sure a project gets done right and within a specified time frame. There are many resources available to project managers that will help them in both planning and plan execution. Charts like the Gantt Chart (or Bar Chart in the PMI world) are helpful in establishing a deadline and marking progress toward that deadline. Most projects, however, need a more detailed project plan. Planning methods such as The Project Management Life Cycle (by PMI) are more practical than Gantt Charts because they include important aspects of planning such as process groups which outline the tages of project development and knowledge areas which break down the process groups into areas of expertise. These methods allow project managers to better distribute their project to employees. Risk management plans help project managers and the project team to anticipate various risks associated with their project and plan for them. Another planning necessity is a resource allocation plan. Resource allocation plans ensure that the appropriate resources are made available for each stage of the project, and are not overused in any of the beginning stages.
37

Instructions 1. Review past Plan and outcomes. Reread previous Plan at his company. Avoid repeating similar projects that were not successful, or consider how a manager can make changes to similar Plan to increase the chances of success. Also review evaluations of previous projects and look for ways you can improve on what has been done. 2. Determine the project's purpose. Write down how the project will meet client or company needs or solve a current problem or issue. Consider how the proposed product or service will enhance target consumers' lives. Include evidence that there is a problem or need. Detail exactly how the proposed project will successfully meet these needs or solve the problem. 3. Evaluate competitors. Visit competitors' websites to see if they have similar offerings. If so, determine how the manager can differentiate his product or service by marketing it to a different group or improving on existing competitor options. 4. Describe how the project will be completed. Create roles for all parties involved and show what they will do to help the project achieve success. 5. Make a list of goals for the project. Write about the ideal outcomes of the project including what it will provide consumers, clients or the company. Create goals that are specific, measurable and important to the company's image, larger goals or strategies. Include a time line for when each goal should be reached.
6. Determine the cost and time line of the project. Decide how long the project will take. Offer a range if manager is not certain. Make a list of resources necessary to sustain the project. Consider personnel, supplies, facilities and other needs. Create a general estimate of how much funding the project will require based on its proposed length and necessary resources. Explain how the project's outcomes will justify its cost. 7. Make a list of potential problems that could arise and prevent the project's success. While risks are often hard to foresee, honestly consider what could go wrong. Brainstorm solutions to potential problems.
38
How to Manage a Project 2.8. Baseline Plan

What is a baseline? A baseline provides a starting point from which a comparison can be made. It is conducted prior to the beginning of the intervention and is the point of comparison for monitoring and evaluation data. The bulk of baseline studies focus on the intended outcomes of a project. They can also take into account secondary outcomes and assumptions, though these are not the primary emphasis. What does a baseline focus on? Baselines explore three areas: Change (outcomes) Secondary changes Assumptions Baseline Planning Process A project has three constraints: scope, schedule and budget. The scope is what the project is to accomplish. Constraints guide the project manager in developing the project plan. First, he defines project requirements that establish the scope. Next, he identifies project activities and their dependencies. This determines the schedule and resource requirements, including staffing. The scope, schedule and resource needs establish the budget. Baseline Information The baseline project plan is not a separate project plan. Software copies the information into baseline fields contained in the original project plan. For example, software copies a tasks start and finish dates into their respective baseline fields. If a project is complex, the project manager might create multiple baselines as an audit trail for numerous baseline changes occurring during project execution. Baseline Updates During project implementation, a project manager might update baseline information to reflect current conditions when unforeseen circumstances occur. For example, a union strike might prevent electricians from performing work. Therefore, the project manager reschedules this effort, as well as other tasks that must begin after the electrical work is completed.
39

Variances A project manager establishes planned start and completion dates for a task. Software calculates the planned duration of the task. She records the start date in the project plan when the task begins. Upon the tasks completion, she enters its completion date. The actual duration is compared to the planned duration to calculate the duration variance. A tasks budget amount, less the tasks total spent and committed amounts, determines the cost variance. Project Control The project manager assesses cost and schedule variances to determine if the project is within budget and on schedule for completion. For example, schedule variances might indicate that project team members completed a group of tasks ahead of schedule. Therefore, the project manager might assign these members to tasks that are behind schedule. If cost variances indicate possible budget overruns, he might decrease the project scope to remain within budget. Considerations Project failure might occur as the result of requirements' creep, known as scope creep. This is work added to a project after it begins, increasing the cost. To address the cost of potential scope creep, you might include a contingency amount in the project. Typically, this amount represents a percent of the total estimated project cost. The Importance of a Baseline Budget for a Project A baseline budget helps measure performance of project management. A baseline budget gives a breakdown of all expected costs of a project. A properly managed project will include a baseline budget so progress may be monitored against expectations. A typical baseline budget contains individual items under the two broad categories of "materials" and "labor." A baseline often includes a time-phased plan. Budget Items A baseline budget must include direct costs, indirect costs, possible contingencies, and expected profit. Direct costs include materials, labor and equipment. Indirect costs include overhead for office space and staff not directly involved with the project, as well as costs for telephones, stationery, postage, travel, taxes and fees.
40

Accountability Adhering to a budget stimulates creativity. When members of a project team have a "money is no object" attitude, they tend to throw money at problems instead of finding creative solutions to them. Changing the Baseline The budget baseline for a project may change for two reasons. The scope of the project may expand, requiring new or more expensive budget items. During the course of the project, one or more tasks may have been underestimated and the baseline must be updated. Busting the Budget Evaluating the progress of the project against the baseline offers the organization the opportunity to change the scope of a project or abort it. A project with heavy cost overruns might expose a weakness in the original estimation of potential profitability, or a weakness in the project manager. Without the baseline, measuring the success or failure of the project is impossible. For example: The table below shows the different areas that should be included in a baseline plan. The baseline focus column always contains the intended change (outcomes) and may include optional areas such as secondary changes or assumptions. The optional areas are depicted by the asterisk in the diagram.
Baseline Plan
Baseline Focus Indicators or Line of Inquiry Change (Outcomes) Secondary Change Assumptions Means of Verification (MOV) & Target Collection Data Source Location of Data Conflict Considerations Means of Analysis Time Needed
41
How to Manage a Project 2.9. Request Project Adjustment

Any changes to an approved grant-funded program must be approved in advance by IDJC. Subrecipients should use the Project Adjustment Request form to request budgetary or programmatic changes as follows: Program Staff The Juvenile Justice Commission must be notified by a Project Adjustment Request of any changes in the Financial Officer or the Project Director. If new personnel are hired, resumes should accompany the Project Adjustment Request. The project adjustment request should be filed no later than 30 days from change of director or officer. Budget Revision If an approved budget item needs to be changed (increase OR decrease), the sub-recipient must secure prior written approval from DJC for any change to a budget category that exceeds five percent (5%) of the approved total project budget. If the change is 5% or less, DJC must be notified in writing of the change. Program Modification Changes to the approved program design must be requested prior to implementation. The adjustment cannot change the scope of the project originally approved by IDJC.
Project Expansion Request IDJC grant recipients may be awarded an extension in response circumstances out of their control provided all the Extension Criteria below are met at the time of the request. Generally, only one extension per award will be permitted.
Expansion Criteria: Time Frame - Requests to extend a project period must be received at 45 days prior to the close of the project. A waiver may be considered in the event emergent issues arise in the final period of the project. Extraordinary Circumstances A narrative justification must be submitted with the extension request providing details justifying the extraordinary circumstances that require the proposed extension.
42

Benefit to the Community A narrative must be submitted describing the benefit of continuing the program. Format Extension requests must be submitted in writing with a signed Project Adjustment Request form as the cover page. Approval Action will be taken on extension requests within 15 business days. Retroactive extensions will not be considered.
Project Adjustment Requests must be signed by the Project Director and submitted to DJC for determination. Requests must include: The specific amount of funds requested for reallocation; The reason for the proposed adjustment needed;
2.10. Work With Plan, But Dont Die For It

Project involving a few activities, resource, constraint and inter-relationship can be visualized easily by the human mind and planed informally. However, when a project crosses a certain threshold level of size and complexity, informal planning has to be substituted by formal planning. The need for formal planning is indeed much greater for project work than for normal operations. Without effective planning, there may be chaos. FUNCTION OF PLANNING Planning, a vital aspect of management, serves several important functions: It provides a basis for organizing the work on the project allocating responsibilities to individuals. It is a means of communication and coordination between all those involved in the project It induces people to look ahead. It instills a sense of urgency and time consciousness.
43

Project Execution: During the project execution, there are many reporting activities to be done. The senior management of the company will require daily or weekly status updates on the project progress. In addition to that, the client may also want to track the progress of the project. During the project execution, it is a must to track the effort and cost of the project in order to determine whether the project is progressing in the right direction or not. In addition to reporting, there are multiple deliveries to be made during the project execution. Usually, project deliveries are not one time deliveries made at the end of the project. Instead, the deliveries are scattered throughout the project execution period and delivered upon agreed timelines. Control and Validation: During the project life cycle, the project activities should be thoroughly controlled and validated. The controlling can be mainly done by adhering to the initial protocols such as project plan, quality assurance test plan, and communication plan for the project. When it comes to project deliveries and requirements, a separate team called 'quality assurance team' will assist the project team for validation and verifications functions. Closeout and Evaluation: Once all the project requirements are achieved, it is time to hand over the implemented system and closeout the project. If the project deliveries are in par with the acceptance criteria defined by the client, the project will be duly accepted and paid by the customer. Once the project closeout takes place, it is time to evaluate the entire project. In this evaluation, the mistakes made by the project team will be identified and will take necessary steps to avoid them in the future projects. During the project evaluation process, the services provider may notice that they haven't gained the expected margins for the project and may have exceeded the timelines planned at the beginning. In such cases, the project is not a 100% success to the services provider. Therefore, such instances should be studied carefully and should take necessary actions to avoid in the future.
44

The Three Constraints: The three constraints in a project management triangle are time, cost and scope. Time A project's activities can either take shorter or longer amount of time to complete. Completion of tasks depends on a number of factors such as the number of people working on the project, experience, skills etc.
Figure: Time
Time is a crucial factor which is uncontrollable. On the other hand, failure to meet the deadlines in a project can create adverse effects. Most often, the main reason for organizations to fail in terms of time is due to lack of resources. Cost It's imperative for both the project manager and the organization to have an estimated cost when undertaking a project. Budgets will ensure that project is developed or implemented below a certain cost. Sometimes, project managers have to allocate additional resources in order to meet the deadlines with a penalty of additional project costs. Scope Scope looks at the outcome of the project undertaken. This consists of a list of deliverables which need to be addressed by the project team. A successful project manager will know to manage both the scope of the project and any change in scope which impacts time and cost.
45

Quality is not a part of the project management triangle, but it is the ultimate objective of every delivery. Hence, the project management triangle represents implies quality. Many project managers are under the notion that 'high quality comes with high cost', which to some extent is true. By using low quality resources to accomplish project deadlines does not ensure success of the overall project. Like with the scope, quality will also be an important deliverable for the project. Project management is a responsible process. The project management process connects all other project activities together and creates the harmony in the project. Therefore, the project management team should have a detailed understanding on the all project management processes and the tools that they can make use for each project management process.
2.11. Monitoring Team Progress

Monitoring progress is about keeping track of how the work with others is going, making sure the team are on task and on time. Manager need to know how to monitor progress in managing a group activity and being a team member. This will involve considering the relationships within the group and managing the quality of the work by using the checkpoints to review the progress towards your goals and outcomes. Monitoring progress in working with others involves manager considering her progress in: managing a group activity to enable the group to achieve its goals effectively and efficiently; establishing and maintaining co-operative working relationships, exchanging feedback and agreeing ways to solve difficulties; and monitoring and critically reflecting on his use of skills in working with others, and adapting his strategy as necessary. Monitor staff progress by: Taking a leading role in managing an activity If the planning has been considered and negotiated and schedules and resources identified, managing the group progress may just involve checking on progress against agreed deadlines. You need to know how to obtain and use effectively the resources needed (such as materials, tools, access to equipment, and help from others) and try to make constructive use of time, both yours and that of other group members. Managing an activity also means being able to delegate and negotiate quality and standards of work to be achieved. If the group works well, collective responsibility should share the load and achieve high-quality outcomes. But some groups work less well than others and require more intervention. You need to be alert to problems such as conflict or apathy and take steps to keep the work on task and on time.
46

Establish and maintain co-operative working relationships Try to organize the work so that each member can benefit from working as part of a team and helpful relationships are maintained. At times you may need to offer support and encouragement, share resources, ask for help and advice yourself, and deal with behavior, which may discriminate against others or disrupt their work, and help to resolve conflict. If you are completely stuck on how to overcome difficulties, try to find someone who can support and help you and the group. Exchange feedback It is important to listen to, and take into account, the views and feelings of others. As a member of the group, you need to provide information on the extent to which your own work is meeting expected timescales and quality requirements: ask for and accept feedback from others on the way you are working and the quality of work being done. These skills take time to develop. Try to establish a climate for learning and developing your skills within the group so you can all actively benefit from the work of the group and each other's comments. Task Manager helps you manage your team effectively and efficiently by showing you the team's progress across all of their tasks. Using a familiar list format, managers can quickly identify and manage individual and team progress based on the tasks being worked on, those completed and the ones that are either nearing a deadline or have fallen behind. Keep the deals moving forward Knowing a sales team's status is critical for helping managers anticipate and support their salespeople and help to move the deal forward. Easily review and manage team progress With Campaigner CRM's Task Manager, you can easily review the progress of each of your team members as well as your entire team, letting you have insight into what's on track, what's coming up and whether anything has fallen behind. Identify and track delays in the sales processes Clearly monitor the progress of tasks by seeing those nearing deadlines and which ones may create delays in the sales flow. Create powerful list reports Generate list reports that organize tasks by individual team members, the whole team , by due dates, types of tasks as well as tasks completed by date/month/quarter and more. Monitor work trends and statistics Stay on top of developing trends and spot opportunities by monitoring progress through your sales process. Assign tasks to keep the process moving Keep the deal moving by delegating tasks to team members for timely follow up.
47

Manage Individual and Team Progress Identify and Track Process Delays List reports Easily review progress of individual team members or your entire team View lists that clearly identify where team members are nearing deadlines and where tasks are overdue Generate actionable lists that can be organized by team members, the entire team, due dates, types of tasks and more Stay alert to opportunities and key events by using the powerful reporting features Easily synchronize tasks with Microsoft Outlook
Work Trends and Statistics Monitoring Outlook synchronization
2.12. Document Everything

If given the choice between installing a brand-new server and writing a procedural document on performing system backups, the average system administrator would install the new server every time. While this is not at all unusual, a manager must document what he does. Good documentation - and organization of that documentation - is essential to a good Project settlement (whether a manager is doing it himself or retaining an attorney) There is no substitute for documentation. His memory cannot do it. He must: DOCUMENT! DOCUMENT! DOCUMENT!
48
Figure: Documentation
Many system administrators put off doing the necessary documentation for a variety of reasons: "He will get around to it later." Unfortunately, this is usually not true. Even if a system administrator is not kidding themselves, the nature of the job is such that everyday tasks are usually too chaotic to "do it later." Even worse, the longer it is put off, the more that is forgotten, leading to a much less detailed (and therefore, less useful) document. "Why write it up? He will remember it." Unless he is one of those rare individuals with a photographic memory, no, manager will not remember it. Or worse, the manager will remember only half of it, not realizing that he is missing the whole story. This leads to wasted time either trying to relearn what he had forgotten or fixing what he had broken due to his incomplete understanding of the situation.
49

"If he keeps it in his head, they will not fire me He will have job security!" While this may work for a while, invariably it leads to less not more job security. Think for a moment about what may happen during an emergency. He may not be available; his documentation may save the day by letting someone else resolve the problem in his absence. And never forget that emergencies tend to be times when upper management pays close attention. In such cases, it is better to have managers documentation be part of the solution than it is for his absence to be part of the problem. Hopefully manager is now sold on the benefits of system documentation. That brings us to the next question: What should he document? Here is a partial list: Policies Policies are written to formalize and clarify the relationship manager have with his user community. They make it clear to his users how their requests for resources and/or assistance are handled. The nature, style, and method of disseminating policies to his a community varies from organization to organization. Procedures Procedures are any step-by-step sequence of actions that must be taken to accomplish a certain task. Procedures to be documented can include backup procedures, user account management procedures, problem reporting procedures, and so on. Like automation, if a procedure is followed more than once, it is a good idea to document it. Changes A large part of a system administrator's career revolves around making changes configuring systems for maximum performance, tweaking scripts, modifying configuration files, and so on. All of these changes should be documented in some fashion. Otherwise, he could find himself being completely confused about a change he made several months earlier. Some organizations use more complex methods for keeping track of changes, but in many cases a simple revision history at the start of the file being changed is all that is necessary. At a minimum, each entry in the revision history should contain: The name or initials of the person making the change The date the change was made The reason the change was made. Three Stages of Records: In the project record management process, there are three distinct stages. These stages have many other activities involved, in order to complete and accomplish the objectives for each stage.
50

The stages are: The creation of records Maintenance of records Storage and retrieval of records Creating Records: This refers to the underlying reason as to why the record is being created. This could be for a receipt or for an inventory control report or some other reason. The primary objective of project record management is to determine the flow of the record handling once the record is created. When it comes to creating records, the following questions should be answered. Maintaining Records: Developing an operation to store the records refers to maintaining the records. The access levels to the records should be defined at this stage and should take all necessary steps in order to avoid the records getting into the wrong hands. Proper compliance procedures and security measures need to be in place to avoid misusing of records. Storing and Retrieval: Storing of records could refer to manual storage of documents as well as digital storage. Project managers need to ensure that the records are returned in the way it was borrowed. Maintaining records also refers to the amount of time that records can be maintained. Some organizations may retain records up to six years whilst others less amount of years. If records are saved digitally, proper folders need to be created. Once created, the older documents need to be archived so that hard drive space is retained. Documentation Management and Control Why, What, How? All projects involve the production and control of documentation. There will be many types of document with varying purposes, natures, and lifecycles. Of course, most information and documentation these days will not be on paper and its format may not even look like a conventional document. There is every reason to use state-of-the-art ideas and technology to share and convey information as efficiently as possible. The concept of document management sounds very authoritarian and bureaucratic. It should not be seen that way nor presented in such terms. It should provide an efficient way of sharing knowledge, information and thinking among the project's participants. All participants should
51

find it easy to consult the project's documentation repository to find all content that is relevant to their interests. It should equally be easy for them to lodge in the repository any documented information that they feel is of value to the team. Documentation Management and Control is closely related to Configuration Management. In some projects they will be treated as part of the same overall process and toolset. More typically, separate management procedures are applied to documentation and technical components. In terms of the lifespan and usage of project information, there are four main scenarios: Permanent External Deliverable Permanent documentation as a deliverable from the project (e.g. "Help" information, User Manuals, Training Materials, Forms, etc.) Temporary Temporary documentation that is an external deliverable from the project but has no value once the project has been completed (e.g. discussion papers, draft documents, interim progress reports, etc.)
Used by Project Team
Permanent documentation to support the maintenance and enhancement of the system (e.g. Design Specifications, Database Definitions, source code, process diagrams, etc.)
Temporary documentation which is only for internal communication (e.g. ideas, issues, control, working papers etc.)
Consider how these factors affect the requirements for quality, review and update. For example:

external deliverables need to be of high quality, whereas internal documents may be informal and incomplete, permanent documentation will need to be updated as circumstances change, but temporary documentation will usually be left unchanged.
As technical solutions improve, and particularly with eSolutions, it is increasingly sensible to make components self-documenting, ie there is not a separate document to be created, stored, accessed and read - the information is directly within the component itself. This is absolutely crucial with business-to-consumer eSolutions - when did you see a customer stopping to download the user manual when ordering from a web storefront? It is equally valuable in terms of other documentation and information, for example:
52

analysis, design and development tools should be self-documenting, development standards for source code should generally ensure it can be easily understood and followed by others, user procedures can be presented through a workflow system, user manuals and help information can be provided incorporated as context-sensitive, on-line information, training materials can be designed for electronic self-study.
Here are some of the functions to look for in a Documentation Management system:
Documentation Management Systems

Catalogue of all controlled documents and deliverables Registration of key information per document, e.g.:

description purpose / objective form and format responsibilities for production responsibilities and rights for review responsibilities for approval further circulation - for information only retention and usage (e.g. temporary or permanent, internal or project deliverable) requirements for update (usually, permanent documentation needs to be updated if something changes after it has been finalized, whereas temporary documentation may be left as a historic record even though something has subsequently been changed) required protocols for review and quality assurance
Tracking of progress and status information per document, e.g.:

planned date of completion current status and effective date persons currently updating or reviewing the document current projected date of completion
Ability to incorporate further documents as required throughout the project Ability to store and issue a template version of each document as a starting point where appropriate Ability to access model examples and other illustrative examples to provide team members with a guide to the content that is required Management of multiple versions
53

Secure storage of documents "Checking out" a copy of a document for update to an authorized team member, ie applying appropriate controls and delivering the document to the team member for update "Checking in" an updated version of a document, ie receiving and storing an updated document with appropriate controls and audit trail Controlling and capturing document status changes - what, who, when, why Providing management views and reports of the status of each document Providing team members search access and viewing access to information (subject to authorization controls) Ability to consult previous historic versions where relevant Ability to identify changes and the reasons for those changes Ability to support a distributed team through Internet, Intranet or WAN networks Analysis of document flow
2.13. Keep Everyone Informed

If the concern person is engaged in team work they can contribute much in a project. A project manager needs to keep all the project-stockholders informed of process of the project. All the project-stockholders are needs to motivate. Rewards and recognition are considered powerful tools which are used by an organization to motivate its employees. Rewards and recognition are remuneration based systems which includes bonus, perks, allowances and certificates. Establish procedures for keeping everyone updated on what has been accomplished and which decisions have been made as the team's work progresses. The challenge is to ensure that team members communicate progress on their parts of the project, and that the resulting information and updates circulate easily among all team members. Leaders of virtual teams should decide who will submit what kinds of information to whom, and how often they will do it. Settle on a method, and then stick to it so that everyone knows what to expect. Communications are a critical deliverable of every successful project and a key project management soft-skill. Manager may not have thought of communications as an actual project deliverable, but it is. It may not be the one his client or customer places the most emphasis on, but that's because every client and customer will take good communications for granted.
54

Project communications is one deliverable that the managers are personally responsible for and it's one that has a large influence over their project's success or failure. We say this because personal experience has taught ourselves that the best managed projects, delivering on all their promises, on time, and on budget can still get a bad reputation and are perceived as failures. The reason: the project manager did not do an adequate job of communicating project success to their stakeholders. The Major Elements of Project Communications Who to communicate to... A manager could just say that it's important to communicate with all the project's stakeholders and leave it at that, but this approach would guarantee failure. Each individual stakeholder has a different set of requirements for project information, and prefers different ways of receiving their communications. It will not be possible to define a unique set of communications and communication vehicles for each stakeholder in most projects, so the best the manager can do is identify the different category of stakeholder and define the required information and communication methods that best suits the group. Executive Sponsor/Business Sponsor Probably the most important customer(s) of his project communications. It's going to be worth his while to define a custom set of communications for each person in this category. Generally speaking, these are busy people who don't have a lot of time to read a lot of detail. Charts and graphs that tell the viewer a lot about the project at a glance will probably work best for them. Take the time to interview them about their preferences: what they need to know, how they want to be communicated with, and how often. Keeping them informed about project performance is critical because they sign the cheque for the project (including your salary). They also need information so they can keep their peers appraised of the project's performance. Remember, they are ours project champions so the better armed with information they are, the better job they can do promoting our project. Project Team Members This is the single most populous group in our list of stakeholders. We may want to subdivide the group into sub-groups based on their roles. For example manager may want to have a different set of communications for the Business Analysts and Software Developers, or for the Electricians and Plumbers on our project. This group has a different perspective on project performance than sponsors: the sponsor views the project as work being done for them. The team member views the project as work being done by them and therefore reports on project performance are a reflection on them. A good report pleases everyone - project sponsors and team members. A bad report will cause the sponsor to worry, but may negatively impact team morale.
55

Customers/Clients These can be internal to our organization, or external to it. These people may profess no particular interest in project communications until the final product or service is delivered. Project manager need to overcome this disinterest and pique their interest in project progress. The more informed they are on the project as it progresses through its lifecycle, the more likely they are to accept the resulting products or services. Partners These are people who are doing work that is in some way affected by the work of our project. Manager may both be working on projects that are part of a programme, or his projects may simply affect one another without further integration. For example, he may be managing a software project that requires a corresponding database project - the database project team is his partner. Or, he may be working on a new software system that will utilize an existing web portal for customer access - the portal team is his partner despite the fact they aren't performing a project. Community Stakeholders These are an increasingly important category of stakeholder. As more emphasis is being placed on organizations ethical behavior and social responsibility, there is an increasing demand for projects to be performed ethically. One of the ways this is done is by treating those who don't belong to the performing organization, or to the customer/client organization, as project stakeholders. Consideration of these stakeholders must go beyond communications, but project communications constitute an important part of managers ethical dealings with them. Project Manager Don't forget to include own self as a stakeholder. I need for project information is perhaps the most important for the project. If the managers aren't receiving the information their need to run the project, they won't be able to share it with other stakeholders. His needs will stem from the need to be updated on the progress of the individual tasks of the project so that he can keep the project plans up to date and identify preventive or corrective actions. Project Management Office (PMO) A project manager PMO may have requirements for project information that will enable it to identify opportunities for process improvement. While these needs are very much like the needs of sponsors, customers, and clients to know how the project is progressing, its focus is on the project processes, tools, techniques, and best practices it supports. The manager PMO may also be tasked with reporting on project progress to the organization. Reports which the PMO is responsible for should provide very specific requirements for information. What to Communicate What project information to communicate to a stakeholder group is inextricably tied to the information that is available for communication. After all, manager cant communicate what he doesnt know. On the other hand, if the need for the information is real and gathering the
56

information is feasible, he should make every effort to make it available. The choice of the information to be communicated cannot be made without considering the project's tools and techniques for gathering the information and vice versa. Project communications is not a key deliverable of the project, but it should be treated as a project deliverable. Start with his Project Charter: does the charter contain any requirements for information? If it does, the information and its target audience ought to be included in your Communications Management Plan. His Scope Statement may also include requirements for project communications. The Statement of Work (SOW) may also have captured requirements for project communications. When project manager are performing a project for an external customer or client the SOW is his bible and any project communications that are part of the legal contract should be specified there. After identifying all the needs already expressed in the project documentation to date, manager needs to solicit requirements from the various groups of stakeholders. This solicitation should be done in the context of what is feasible for the project to deliver. Be prepared to meet with our sponsor to identify their requirements. Be specific as to presentation: should the SPI (Schedule Performance Index) be shown as a bar graph with a rolling 6 week tally? Should it be shown as a line graph with the benchmark line of 1.0 and a rolling 6 month tally? Manager may even want to mock up some sample reports to let them choose the format. A project dashboard is a popular instrument for communicating project progress to sponsors and other senior executives. The dashboard is meant to show the status of our project at a glance and may consist of the project's SPI, CPI (Cost Performance Index), SV (Schedule Variance), CV (Cost Variance), PV (Planned Value), AC (Actual Cost), and EV (Earned Value). As a rule, manager shouldn't mix schedule indicators with cost indicators, but he can show schedule and cost indicators in any combination your sponsor would like. manager may also want to include such things as the top 5 risks, top 5 outstanding issues, metrics on change (number of change requests, number accepted, number of rejected, total costs, etc.), and quality (number of tests, number passed, number failed, outstanding bug reports, etc.). He should try to keep your dashboard to a handful of slides and provide supporting detail in text, or Excel format as backup. Manager should repeat the requirements gathering exercise with each group of stakeholders, weighing their need for information with the project's ability to gather and communicate it. Be prepared to capture and report information by stakeholder group, department, or subproject. The individual groups on your team will want the ability to view their progress in isolation from the rest of the team. The information he plans to communicate will drive his activities throughout the project. Our plans should include the metrics that must be gathered in order to support the information we plan to communicate. He will need to identify who is responsible for providing the information and where the information is to be stored and reported from. There are two questions he needs to ask himself before his commit to providing a report:
57

1. How do I get this information? (i.e. what metrics do I need to capture and where will they come from) 2. Where will I store the metrics? A failure to answer both questions will mean that either manager have to alter is plan to task someone to gather the metrics, identify a tool to capture and retrieve the metrics, or drop the requirement. Finally, don't forget individual accomplishments and rewards when reporting project progress. There's nothing like a good news story to keep team morale high and the celebration of a team member's accomplishment is something most sponsors enjoy hearing about. How to Communicate There are many different means of communication available to manager - face to face, e-mail, Intranet, Internet, regular mail, phone, video conferences, etc., etc. These can be grouped into 2 groups: "push" communications and "pull" communications. Push communications requires manager to push the information onto the recipient as the name would suggest, while pull communications requires the recipient to actively retrieve the information from a central source. Websites and centralized repositories are examples of pull communications, while email and meetings are examples of push communications. Preference for either push or pull communications is typically a personal preference. Some people deal with information best when it's presented to them and some prefer to retrieve it at their own convenience. Be prepared for conflicting requirements from individuals in our stakeholder groups. Manager may have to make the final decision on which method to use if there are conflicting requests. Alternatively, manager may be able to identify a spokesperson for the group who will be empowered to identify the group's requirements. The exception to this rule is our project's sponsor. Because there is only one or two of these people, manager need to ensure that his communication methods suit their requirements. When to Communicate A project manager communication schedule will be driven by the needs of his audience and the availability of the information to be communicated. For example, if he had the bandwidth, he could report on any metrics managed by his MS Project file daily. On the other hand, he can't report on the results of his Gate Meeting until the Gate Meeting has actually been held. There is also no reason that a report communicated to one stakeholder group bi-weekly, can't be communicated to another group every week. Manager need to use common sense in addition to capturing his stakeholders' requirements. If he chooses to use a "town hall" to communicate to all stakeholders, don't schedule the meeting to occur weekly. Other meetings, such as status review meetings with project teams must be done more often to avoid the project going off the rails. We find that when the project is on track, weekly status review meetings are sufficient. When his project encounters problems, he might want to
58

increase the frequency to better control the work. In extreme cases such as a project rescue, he may need to hold them daily. Remember that communications is part of the project work. Manager should manage that work in his MS Project file like other project tasks, but be sensible - don't overload himself by tracking every meeting in MS Project. He should be using the "walk around" style of management if his team is collocated; he needn't track each informal meeting he has with individual team members. Use MS Project to help manager control the project, not overloads him with work. Tools and Techniques Tools and techniques include tools manager will use to convey the information, tools he'll use to gather the information, and tools he'll use to store and retrieve the information. Conveyance tools will include e-mail, websites, webcasts, conference calls, video conferencing, public directories, town hall meetings, and graphical tools such as Excel. What he is communicating, how you need to communicate it, and his communication budget will determine which of these tools he will use. There is one tool that he'll rely on more than any other to manage information about his project: MS Project. These tools are referred to as Project Management Information Systems (PMIS) by most PMP Exam preparation courses and in the PMBOK. These tools are capable of capturing, manipulating, and reporting most of his project's relevant information so you need to be very familiar with their use. There are many excellent courses available that will ground you in the fundamentals of their use. Project managers organization may employ a time tracking system in which case he have an additional source of information. His time tracking tool should allow he to report on labor costs for his project (i.e. support the charging of time to his project code). It should also support the reporting of these costs by group and by type of work. For example it should tell you how much time was spent last week on analysis of his software project. He should reconcile the metrics from the time tracking system with his MS Project file to ensure they tally.
03. Conclusion
As a conclusion, the usage of scientifically method such as Gantt chart, AOA, AON, PERT, and Project time reduction and cost minimization are compulsory in order to get the large project completed timely. Cost factor is another agenda that needs to be highlighted and it is need to be tackle thoroughly in order to reduce the unnecessary cost incurs. The qualitative skill amongst the project manager also need to be concern, because without the qualitative skills the project manager will not successfully manage the project based on the scientifically method.
59
How to Manage a Project 04. Reference:

01. Projects Planing, analysis, selection, finacing, implementation, and review by Dr. Prasanna Chadra (7th edition). 02. Cliffoerd F.Gray,Erik W. Larson, Project Management: The Management Process. 03. Free Management Library, Project Management, available: http://www.managementhelp.org/plan_dec/project/project.htm 04. Mind Tools, Project management Tools, Gantt chart. Available: http://www.mindtools.com/pages/main/article/newMN_PPM.htm 05. ibid (PERT) 06. Harvey Maylor, (2001)Project Management, third edition, Prentice Hill, financial Times. 07. Jack R. Merdith,(2005) Project Management, A Marginal Approach. John Wiley & Sons.
THE END
60

How To Manage A Project (Project Management)

Uploaded by

Document Information

Original Title

Copyright

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

How To Manage A Project (Project Management)

Uploaded by

Copyright:

How to Manage a Project