Project Management

Project Management Processes

Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. Project management is accomplished through processes, using project management knowledge, skills, tools, and techniques that receive inputs and generate outputs.

 

In order for a project to be successful, the project team must:

 

·        Select appropriate processes within the Project Management Process Groups (also known as Process Groups) that are required to meet the project objectives

·        Use a defined approach to adapt the product specifications and plans to meet project and product requirements

·        Comply with requirements to meet stakeholder needs, wants and expectations

·        Balance the competing demands of scope, time, cost, quality, resources, and risk to produce a quality product.

 

The PMBOK documents information needed to initiate, plan, execute, monitor and control, and close a single project, and identifies those project management processes that have been recognized as good practice on most projects most of the time. These processes apply globally and across industry groups. Good practice means there is general agreement that the application of those project management processes has been shown to enhance the chances of success over a wide range of projects.

 

A process is a set of interrelated actions and activities that are performed to achieve a pre-specified set of products, results, or services. The project processes are performed by the project team, and generally fall into one of two major categories:

 

·        The project management processes common to most projects most of the time are associated with each other by their performance for an integrated purpose. The purpose is to initiate, plan, execute, monitor and control, and close a project. These processes interact with each other in complex ways that cannot be completely explained in a document or with graphics The processes may also interact in relation to project scope, cost, schedule, etc., which are called Knowledge Areas

·        Product-oriented processes specify and create the project’s product. Product oriented processes are typically defined by the project life cycle and vary by application area. Project management processes and product-oriented processes overlap and interact throughout the project. For example, the scope of the project cannot be defined in the absence of some basic understanding of how to create the specified product.

 

Project management is an integrative undertaking. Project management integration requires each project and product process to be appropriately aligned and connected with the other processes to facilitate their coordination. These process interactions often require tradeoffs among project requirements and objectives. A large and complex project may have some processes that will have to be iterated several times to define and meet stakeholder requirements and reach agreement on the processes outcome.

 

Failure to take action during one process will usually affect that process and other related processes. For example, a scope change will almost always affect project cost, but the scope change may or may not affect team morale or product quality. The specific performance tradeoffs will vary from project to project and organization to organization. Successful project management includes actively managing these interactions to successfully meet sponsor, customer and other stakeholder requirements.

 

The PMBOK describes the nature of project management processes in terms of the integration between the processes, the interactions within them, and the purposes they serve. These processes are aggregated into five groups, defined as the Project Management Process Groups:

 

·         Initiating Process Group

·         Planning Process Group

·         Executing Process Group

·         Monitoring and Controlling Process Group

·         Closing Process Group.

 

Advertisements

November 10, 2008 Posted by | PMP, Project Management | , , | Leave a comment

How to Produce a Great Project!

Some folks say that hiring good Project Managers is now more science than art. I have always found that meeting a person and talking with them providing examples of project problems and hearing their approach and final answer to solving the problem is vital.

PMP certified project managers understand Project Management at a certain level as defined by the requirements set by PMI. Those requirements include a number of hours of experience and training before allowing them to even take the certification test. Then they take the test and after passing it they receive their PMP certification.

If the person you are trying to hire has the certification, you can assume that they understand project management, scope management, risks to a project, schedule management, quality management, communications management  and can notify management of potential issues. To see what they are taught you can look at the PMBOK located on www.pmi.org.

They have had hands on experience creating project plans and all the necessary artifacts to ensure a smooth running project. Certified PMPs have to have a few good-sized projects under their belts before they get this certification. They also have to have 30 hours of PMI certified training.

Sometimes you need to go deeper than the PMP certification. The certification tells you that they meet the standardized requirements of a Project Management Professional, but it does not address style, critical thinking, and approach to challenges, personality and more importantly, motivation. I am a very relational person, and I can usually tell in a few minutes if a person will click with the culture and customer they will be dealing with.

What PMOs need are Project Managers who have a project management core knowledge set and experience with visioning skills, leadership skills, a quality focus and a knowledge of all the PMP tools and tricks.

The Project Manager and the Business Analyst get all the requirements down working with Stakeholders. The business manager signs off on the core elements. The Project Manager creates all of the elements of the Project Plan and then the Project Manager monitors and controls the project on a daily basis.

Engineers often say “we can do it this way to meet the timeline, but this feature won’t be available” and the project manager says “we need that feature and the deadline is immovable.”  This is when the Change Management process comes in. Each Project should have a Change Management team and process. Options are shown to the Change Management team, often trading off either time to market, resources or functionality. Sometimes, if the change is approved, something different than the original project plan occurs and the original Project documentation is updated. If time to market is not changed, the product may be released on schedule, but fizzles. $xx million is not realized and the project is a failure. The project manager did his job. It was released on time and within budget, right?

The Project Manager is so wrapped up in project risk factors, slipping schedule, and budget that he/she can’t see the forest for the trees. Once you are in a project, there are pressures from all sides. The developer can’t do it this way unless he re-writes an entire module causing a two-month delay. Or the developer says that something just can’t be done and pushes back on the Project Manager. Or the business manager cannot articulate why something needs to be a certain way.

What is needed here is a Project Manager with the knowledge and the intestinal fortitude to push hard. She pushes herself hard to fully understand the vision of the business manager: All the subtleties, all the subjective qualities and the reasons for each of them. She doesn’t stop pushing herself until she fully sees the vision of the business manager and that vision becomes hers as well. Now you have someone who understands technology and sees the full vision of what is needed to make the $xx million in 18 months.

Now this type of Project Manager pushes back on the developer. She knows if the developer is trying to blow by a fast ball. She also has the leadership skills to push the team above and beyond in order to fully realize the vision. Short cuts and compromises are not part of the process. “Not good enough” is frequently uttered by this Project Manager. If something is more difficult than anticipated, the Project Manager can speak with the change management team and fully explain the benefits of a delay or the impact of adding the feature or function in a follow-up release. If the feature is going to take two months, the Project Manager works her leadership magic and pushes the team to get it done in one month. She examines the critical path; she may move resources around and do whatever it takes to come in on time.

Developers are a very smart and creative group. There are always new ways to approach something to trim a schedule and still meet or exceed requirements. They love to build a Cadillac when the project plan calls for a Volkswagen. They just need to be led appropriately. I’ve never met a developer who didn’t love a challenge. They just hate getting beat up all the time for missed schedules or a buggy product that tends to be out of their control anyway. When you let a good developer be a good developer, you get amazing results.

Now all the tools and tricks the Project Manager learned during PMP certification come into play. These tools combined with leadership skills, visioning skills and a quality focus makes this Project Manager a Seasoned Project Manager.

Finding a Seasoned Project Manager is no easy task, because basically, you’re hiring your replacement. See how succession planning just kind of happens when you hire the right people?

So where have these Seasoned-Project Managers come from? One successful combination is a very good Business Analyst that became a developer and then moved into project management. Good Business Analysts inject themselves into the visioning process when they’re gathering requirements. They just become too far removed during the development from the finished product to really have an impact on product quality during the process. That frustration is typically what drives these Business Analysts to become developers and then Project Managers. This combination has worked six out of seven times for me personally.

During an interview, ask the candidate to define visioning. How has that candidate used visioning in the past? How has this skill led to delivering successful solutions? Have the candidate tell you about a project that failed and why. What were the lessons learned? What would he/she have done differently? Did they keep a record of the lessons learned so that they can use this historical data for the next project?

Ask the candidates to describe their relationship with the technical teams. Find out if it was an adversarial relationship or more of a high-powered team. If it was more of a team environment, you should see a change in the candidate’s face when he/she describes it. These Seasoned Project Managers thrive in team environments. They have an inherent, almost genetic, understanding that things can never be done alone and can describe how, at times; the team members could almost read each others’ mind.

Ask candidates to define “good enough.” When you hear enough of these answers, you’ll know what you’re looking for and more importantly, what you don’t want. This is just an opinion based upon my personal experience. I started out as a Software Engineer and moved on to Manage/Direct engineering groups. When I got my PMP I was well equipped to work with the Software team.

Great projects are like great works of art. They are memorable and live beyond their time!

 

November 6, 2008 Posted by | Business Analyst, PMP, Project Management | , , , , | Leave a comment

Organizational Influences on a Project

Projects are typically part of an organization that is larger than the project.

Examples of organizations include corporations, government agencies, healthcare institutions, international bodies, professional associations, and others. Even when the project is external (joint ventures, partnering), the project will still be influenced by the organization or organizations that initiated it.

 

The maturity of the organization with respect to its project management system, culture, style, organizational structure and project management office can also influence the project. The following sections describe key aspects of these larger organizational structures that are likely to influence the project.

 

I have worked as a Project Manager in all of these types of organizations. There are pros and cons of each listed below. It is vital that the organizational structure is clear and known to all for the project to run smoothly.  

 

Project-based organizations are those whose operations consist primarily of projects. These organizations fall into two categories:

 

Organizations that derive their revenue primarily from performing projects for others under contract – architectural firms, engineering firms, consultants, construction contractors, and government contractors.

Organizations that have adopted management by projects. These organizations tend to have management systems in place to facilitate project management. For example, their financial systems are often specifically designed for accounting, tracking, and reporting on multiple, simultaneous projects.

 

Non-project-based organizations often may lack management systems designed to support project needs efficiently and effectively. The absence of project-oriented systems usually makes project management more difficult. In some cases, non-project-based organizations will have departments or other subunits that operate as project-based organizations with systems to support them. The project management team should be aware of how its organization’s structure and systems affect the project.

 

Organizational Cultures and Styles

Most organizations have developed unique and describable cultures. These cultures are reflected in numerous factors, including, but not limited to:

Shared values, norms, beliefs, and expectations

Policies and procedures

View of authority relationships

Work ethic and work hours.

Organizational cultures often have a direct influence on the project. For example:

A team proposing an unusual or high-risk approach is more likely to secure approval in an aggressive or entrepreneurial organization

A project manager with a highly participative style is apt to encounter problems in a rigidly hierarchical organization, while a project manager with an authoritarian style will be equally challenged in a participative organization.

 

Organizational Structure

The structure of the performing organization often constrains the availability of resources in a spectrum from functional to projectized, with a variety of matrix structures in between.

 

The classic functional organization is a hierarchy where each employee has one clear superior. Staff members are grouped by specialty, such as production, marketing, engineering, and accounting at the top level.

Engineering may be further subdivided into functional organizations that support the business of the larger organization, such as mechanical and electrical.

 

Functional organizations still have projects, but the scope of the project is usually limited to the boundaries of the function. The engineering department in a functional organization will do its project work independent of the manufacturing or marketing departments. When new product development is undertaken in a purely functional organization, the design phase, often called a design project, includes only engineering department staff. Then, when questions about manufacturing arise, they are passed up the organizational hierarchy to the department head, who consults with the head of the manufacturing department. The engineering department head then passes the answer back down the hierarchy to the engineering functional manager. These organizations are good for having a clear career path for project team members when the project ends.

 

Projectized organizations have team members that are often collocated. Most of the organization’s resources are involved in project work, and project managers have a great deal of independence and authority. Projectized organizations often have organizational units called departments, but these groups either report directly to the project manager or provide support services to the various projects.

 

Matrix organizations are a blend of functional and projectized characteristics. Weak matrices maintain many of the characteristics of a functional organization and the project manager role is more that of a coordinator or expediter than that of a manager. In similar fashion, strong matrices have many of the characteristics of the projectized organization, and can have full-time project managers with considerable authority and full-time project administrative staff. While the balanced matrix organization recognizes the need for a project manager, it does not provide the project manager with the full authority over the project and project funding.

Such a team may have many of the characteristics of a project team in a projectized organization. The team may include full-time staff from different functional departments, may develop its own set of operating procedures and may operate outside the standard, formalized reporting structure.[i]

 


[i] A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Third Edition

32 2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

 

November 4, 2008 Posted by | Communications Management, Project Management | | 2 Comments

Characteristics of a Project Phase

The completion and approval of one or more deliverables characterizes a project phase. A deliverable is a measurable, verifiable work product such as a specification, feasibility study report, detailed design document, or working Proto-type. Proto-types are an excellent way to demonstrate the technology to stakeholders and to prove certain methods without the expenditure of a full project. Some deliverables can correspond to the project management process, whereas others are the end products or components of the end products for which the project was conceived. The deliverables, and hence the phases, are part of a generally sequential process designed to ensure proper control of the project and to attain the desired product or service, which is the objective of the project.

 

In any specific project, for reasons of size, complexity, level of risk, and cash flow constraints, phases can be further subdivided into sub-phases. Each sub-phase is aligned with one or more specific deliverables for monitoring and control. The majority of these sub-phase deliverables are related to the primary phase deliverable, and the phases typically take their names from these phase deliverables: requirements, design, build, test, startup, turnover, and others, as appropriate. Each one of these major phases should have a formal sign-off with the stakeholders. Any change made to the scope of the project later on means that you need to re-open the previous phases to examine what changes occur to the schedule, resources, risks etc. because of the scope change.

 

A project phase is generally concluded with a review of the work accomplished and the deliverables to determine acceptance, whether extra work is still required, or whether the phase should be considered closed. A management review is often held to reach a decision to start the activities of the next phase without closing the current phase, for example, when the project manager chooses fast tracking as the course of action. Another example is when an information technology company chooses an iterative life cycle where more than one phase of the project might progress simultaneously. Requirements for a module can be gathered and analyzed before the module is designed and constructed. While analysis of a module is being done, the requirements gathering for another module could also start in parallel.

 

Similarly, a phase can be closed without the decision to initiate any other phases. For example, the project is completed or the risk is deemed too great for the project to be allowed to continue.

 

Formal phase completion does not include authorizing the subsequent phase.

For effective control, each phase is formally initiated to produce a phase-dependent output of the Initiating Process Group, specifying what is allowed and expected for that phase. A phase-end review can be held with the explicit goals of obtaining authorization to close the current phase and to initiate the subsequent one. Sometimes both authorizations can be gained at one review. Phase-end reviews are also called phase exits, phase gates, or kill points. Kill points are when the stakeholders decide that the project is not worth completing in its current state. It may be restarted with different criteria.

 

Project Life Cycle Relationships

Many projects are linked to the ongoing work of the performing organization.

Some organizations formally approve projects only after completion of a feasibility study, a preliminary plan, or some other equivalent form of analysis; in these cases, the preliminary planning or analysis takes the form of a separate project. For example, additional phases could come from developing and testing a prototype prior to initiating the project for the development of the final product. Some types of projects, especially internal service or new product development projects can be initiated informally for a limited amount of time to secure formal approval for additional phases or activities.

 

The driving forces that create the stimuli for a project are typically referred to as problems, opportunities, or business requirements. The effect of these pressures is that management generally must prioritize this request with respect to the needs and resource demands of other potential projects.

The project life cycle definition will also identify which transitional actions at the end of the project are included or not included, in order to link the project to the ongoing operations of the performing organization. Examples would be when a new product is released to manufacturing, or a new software program is turned over to marketing. Care should be taken to distinguish the project life cycle from the product life cycle. For example, a project undertaken to bring a new desktop computer to market is only one aspect of the product life cycle.  Additional projects can include a performance upgrade to the product. In some application areas, such as new product development or software development, organizations consider the project life cycle as part of the product life cycle.

 

[1] ©2005 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA 5

 

October 27, 2008 Posted by | Phase Review Process, Project Management | , , , , | 4 Comments

Definitions of Project Phases

Projects and project management are carried out in an environment broader than that of the project itself. The project management team must understand this broader context so it can select the life cycle phases, processes, and tools and techniques that appropriately fit the project. This chapter describes some key aspects of the project management context.

 

Project managers or the organization can divide projects into phases to provide better management control with appropriate links to the ongoing operations of the performing organization. Collectively, these phases are known as the project life cycle. Many organizations identify a specific set of life cycles for use on all of their projects. I have found, in my experience, that it is best to have all of the stakeholders sign-off each phase. That way, if new requirements or more complex design work is needed on a module, the project should revisit each project phase to ensure that the completed project match all of the preceding documentation.

 

The project life cycle defines the phases that connect the beginning of a project to its end. For example, when an organization identifies an opportunity to which it would like to respond, it will often authorize a feasibility study to decide whether it should undertake the project. The project life cycle definition can help the project manager clarify whether to treat the feasibility study as the first project phase or as a separate, stand-alone project. Where the outcome of such a preliminary effort is not clearly identifiable, it is best to treat such efforts as a separate project. The phases of a project life cycle are not the same as the Project Management Process Groups.

 

The transition from one phase to another within a project’s life cycle generally involves, and is usually defined by, some form of technical transfer or handoff. Deliverables from one phase are usually reviewed for completeness and accuracy and approved before work starts on the next phase. However, it is not uncommon for a phase to begin prior to the approval of the previous phase’s deliverables, when the risks involved are deemed acceptable. This practice of overlapping phases, normally done in sequence, is an example of the application of the schedule compression technique called fast tracking.

 

NOTE: this practice of starting a phase before the other is complete is very normal, but does come with some risk that must be managed by the Project Manager. In some cases, rework has to be done.

 

There is no single best way to define an ideal project life cycle. Some organizations have established policies that standardize all projects with a single life cycle, while others allow the project management team to choose the most appropriate life cycle for the team’s project. Further, industry common practices will often lead to the use of a preferred life cycle within that industry.

 

NOTE: there are many ways to do a Life Cycle. Some projects are more aligned with the waterfall technique, while others benefit from a rapid development technique such as AGILE.

 

Project life cycles generally define:

 

What technical work to do in each phase (for example, in which phase should the architect’s work be performed?)

When the deliverables are to be generated in each phase and how each deliverable is reviewed, verified, and validated

Who is involved in each phase (for example, concurrent engineering requires that the implementers be involved with requirements and design)

How to control and approve each phase. Project life cycle descriptions can be very general or very detailed. Highly detailed descriptions of life cycles can include forms, charts, and checklists to provide structure and control.

Most project life cycles share a number of common characteristics.

Phases are generally sequential and are usually defined by some form of technical information transfer or technical component handoff. Here is where I recommend formal sign-off to occur by all project stakeholders. Scope creep is one of the most prevalent things that slip a schedule, but if management knows what the added scope will do to the project schedule, they will be less likely to add functionality to the project.

Cost and staffing levels are low at the start, peak during the intermediate phases, and drop rapidly as the project draws to a conclusion.

 

The level of uncertainty is highest and, hence, risk of failing to achieve the objectives is greatest at the start of the project. The certainty of completion generally gets progressively better as the project continues. This is because the hardest technical work is usually done (or well understood) and most risks have been mitigated.

 

The ability of the stakeholders to influence the final characteristics of the project’s product and the final cost of the project is highest at the start, and gets progressively lower as the project continues. A major contributor to this phenomenon is that the cost of changes and correcting errors generally increases as the project continues.

 

Although many project life cycles have similar phase names with similar deliverables, few life cycles are identical. Some can have four or five phases, but others may have nine or more. Single application areas are known to have significant variations. One organization’s software development life cycle can have a single design phase, while another can have separate phases for architectural and detailed design. Subprojects can also have distinct project life cycles. For example, an architectural firm hired to design a new office building is first involved in the owner’s definition phase while doing the design, and in the owner’s implementation phase while supporting the construction effort. The architect’s design project, however, will have its own series of phases from conceptual development, through definition and implementation, to closure. The architect can even treat designing the facility and supporting the construction as separate projects, each with its own set of phases.

 

In the next post, I will talk more about the characteristics of Project Phases.

 

 [1] ©2005 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA 5

October 26, 2008 Posted by | Project Management, Project Phases | , , , | 1 Comment

Manage Your Stakeholders! The Key to Your Project’s Success!

 

Project stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be affected as a result of project execution or project completion. Take it from me – these are the people you need to pay the most attention to. They need to be identified in your planning – especially in your communication plan.  They may also exert influence over the project’s objectives and outcomes. The project management team must identify the stakeholders, determine their requirements and expectations, and, to the extent possible, manage their influence in relation to the requirements to ensure a successful project. They can make or break a project!

 

Stakeholders have varying levels of responsibility and authority when participating on a project and these can change over the course of the project’s life cycle. Their responsibility and authority range from occasional contributions in surveys and focus groups to full project sponsorship, which includes providing financial and political support. Stakeholders who ignore this responsibility can have a damaging impact on the project objectives.

 

Likewise, project managers who ignore stakeholders can expect a damaging impact on project outcomes. Sometimes, stakeholder identification can be difficult. For example, some would argue that an assembly-line worker whose future employment depends on the outcome of a new product-design project is a stakeholder. Failure to identify a key stakeholder can cause major problems for a project. For example, late recognition that the legal department was a significant stakeholder in a year 2000 rollover (Y2K) software upgrade project caused many additional documentation tasks to be added to the project’s requirements.

 

Stakeholders may have a positive or negative influence on a project. Positive stakeholders are those who would normally benefit from a successful outcome from the project, while negative stakeholders are those who see negative outcomes from the project’s success. For example, business leaders from a community that will benefit from an industrial expansion project may be positive stakeholders because they see economic benefit to them community from the project’s success. Conversely, environmental groups could be negative stakeholders if they view the project as doing harm to the environment. In the case of positive stakeholders, their interests are best served by helping the project succeed, for example, helping the team to acquire the needed permits to proceed. The negative stakeholders’ interest would be better served by impeding the project’s progress by demanding more extensive environmental reviews. Negative stakeholders are often overlooked by the project team at the risk of failing to bring their projects to a successful end.

 

Key stakeholders on every project include:

 

Project manager. This is the person responsible for managing the project.

Customer/user. This refers to the person or organization that will use the project’s product. There may be multiple layers of customers. For example, the customers for a new pharmaceutical product can include the doctors who prescribe it, the patients who take it and the insurers who pay for it. In some application areas, customer and user are synonymous, while in others, customer refers to the entity acquiring the project’s product and users are those who will directly utilize the project’s product.

Performing organization. This refers to the enterprise whose employees are most directly involved in doing the work of the project.

Project team members. This is the group that is performing the work of the project.

Project management team. These are the members of the project team who are directly involved in project management activities.

Sponsor. This is the person or group that provides the financial resources, in cash or in kind, for the project.

Influencers. People or groups that are not directly related to the acquisition or use of the project’s product, but due to an individual’s position in the customer organization or performing organization, can influence, positively or negatively, the course of the project.

PMO. If it exists in the performing organization, the PMO can be a stakeholder if it has direct or indirect responsibility for the outcome of the project. In addition to these key stakeholders, there are many different names and categories of project stakeholders, including internal and external, owners and investors, sellers and contractors, team members and their families, government agencies and media outlets, individual citizens, temporary or permanent lobbying organizations, and society-at-large. The naming or grouping of stakeholders is primarily an aid to identifying which individuals and organizations view themselves as stakeholders. Stakeholder roles and responsibilities can overlap, such as when an engineering firm provides financing for a plant that it is designing. Project managers must manage stakeholder expectations, which can be difficult because stakeholders often have very different or conflicting objectives.

 

For example:

 

The manager of a department that has requested a new management information system may desire low cost, the system architect may emphasize technical excellence, and the programming contractor may be most interested in maximizing its profit.

The vice president of research at an electronics firm may define new product success as state-of-the-art technology, the vice president of manufacturing may define it as world-class practices, and the vice president of marketing may be primarily concerned with the number of new features.

October 23, 2008 Posted by | Communications Management, Project Management | , | 1 Comment

Construtcing a Project Charter – the Beginning of the Project Scope

 

 

The project charter is the document that formally authorizes a project. The project charter provides the project manager with the authority to apply organizational resources to project activities. A project manager is identified and assigned as early in the project as is feasible. The project manager should always be assigned prior to the start of planning, and preferably while the project charter is being developed.

 

A project initiator or sponsor external to the project organization, at a level that is appropriate to funding the project, issues the project charter. Projects are usually chartered and authorized external to the project organization by an enterprise, a government agency, a company, a program organization, or a portfolio organization, as a result of one or more of the following:

 

A market demand (e.g., a car company authorizing a project to build more fuel-efficient cars in response to gasoline shortages)

A business need (e.g., a training company authorizing a project to create a new course to increase its revenues)

A customer request (e.g., an electric utility authorizing a project to build a new substation to serve a new industrial park)

A technological advance (e.g., an electronics firm authorizing a new project develop a faster, cheaper, and smaller laptop after advances in computer memory and electronics technology)

A legal requirement (e.g., a paint manufacturer authorizing a project to establish guidelines for handling toxic materials)

A social need (e.g., a nongovernmental organization in a developing country authorizing a project to provide potable water systems, latrines, and sanitation education to communities suffering from high rates of cholera).

These stimuli can also be called problems, opportunities, or business requirements. The central theme of all these stimuli is that management must make a decision about how to respond and what projects to authorize and charter. Project selection methods involve measuring value or attractiveness to the project owner or sponsor and may include other organizational decision criteria. Project selection also applies to choosing alternative ways of executing the project.

Chartering a project links the project to the ongoing work of the organization. In some organizations, a project is not formally chartered and initiated until completion of a needs assessment, feasibility study, preliminary plan, or some other equivalent form of analysis that was separately initiated. Developing the project charter is primarily concerned with documenting the business needs, project justification, current understanding of the customer’s requirements, and the new product, service, or result that is intended to satisfy those requirements. The project charter, either directly, or by reference to other documents, should address the following information:

Requirements that satisfy customer sponsor, and other stakeholder needs, wants and expectations;

 

Business needs, high-level project description, or product requirements that the project is undertaken to address

Project purpose or justification

Assigned Project Manager and authority level

Summary milestone schedule

Stakeholder influences

Functional organizations and their participation

Organizational, environmental and external assumptions

Organizational, environmental and external constraints

Business case justifying the project, including return on investment

Summary budget.

 

During subsequent phases of multi-phase projects, the Develop Project

Charter process validates the decisions made during the original chartering of the project. If required, it also authorizes the next project phase, and updates the charter.

 

Contract (When Applicable)

A contract from the customer’s acquiring organization is an input if the project is being done for an external customer.

Project Statement of Work:

The statement of work (SOW) is a narrative description of products or services to be supplied by the project. For internal projects, the project initiator or sponsor provides the statement of work based on business needs, product, or service requirements. For external projects, the statement of work can be received from the customer as part of a bid document, for example, request for proposal, request for information, request for bid, or as part of a contract. The SOW indicates a:

 

Business need – an organization’s business need can be based on needed training, market demand, technological advance, legal requirement, or governmental standard.

Product scope description – documents the product requirements and characteristics of the product or service that the project will be undertaken to create. The product requirements will generally have less detail during the initiation process and more detail during later processes, as the product characteristics are progressively elaborated. These requirements should also document the relationship among the products or services being created and the business need or other stimulus that causes the need. While the form and substance of the product requirements document will vary, it should always be detailed enough to support later project planning.

Strategic plan – all projects should support the organization’s strategic goals. The strategic plan of the performing organization should be considered as a factor when making project selection decisions.

 

Enterprise Environmental Factors:

When developing the project charter, any and all of the organization’s enterprise environmental factors and systems that surround and influence the project’s success must be considered. This includes items such as, but not limited to:

 

Organizational or company culture and structure

Governmental or industry standards (e.g., regulatory agency regulations, product standards, quality standards, and workmanship standards)

Infrastructure (e.g., existing facilities and capital equipment)

Existing human resources (e.g., skills, disciplines, and knowledge, such as design, development, legal, contracting, and purchasing)

Personnel administration (e.g., hiring and firing guidelines, employee performance reviews, and training records)

Company work authorization system

Marketplace conditions

Stakeholder risk tolerances

Commercial databases (e.g., standardized cost estimating data, industry risk study information, and risk databases)

Project management information systems (e.g., an automated tool suite, such as a scheduling software tool, a configuration management system, an information collection and distribution system, or web interfaces to other online automated systems.

 

Organizational Process Assets

When developing the project charter and subsequent project documentation, any and all of the assets that are used to influence the project’s success can be drawn from organizational process assets. Any and all of the organizations involved in the project can have formal and informal policies, procedures, plans, and guidelines whose effects must be considered. Organizational process assets also represent the organizations’ learning and knowledge from previous projects; for example, completed schedules, risk data, and earned value data. Organizational process assets can be organized differently, depending on the type of industry, organization, application area. For example, the organizational process assets could be grouped into two categories:

 

 Organization’s processes and procedures for conducting work:

·    Organizational standard processes, such as standards, policies (e.g., safety and health policy, and project management policy), standard product and project life cycles, and quality policies and procedures (e.g., process audits, improvement targets, checklists, and standardized process definitions for use in the organization)

·    Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria templates (e.g., risk templates, work breakdown structure templates, and project schedule network diagram templates)

·    Guidelines and criteria for tailoring the organization’s set of standard processes to satisfy the specific needs of the project

·    Organization communication requirements (e.g., specific communication technology available, allowed communication media, record retention, and security requirements)

·    Project closure guidelines or requirements (e.g., final project audits, project evaluations, product validations, and acceptance criteria)

·    Financial controls procedures (e.g., time reporting, required expenditure and disbursement reviews, accounting codes, and standard contract provisions)

·    Issue and defect management procedures defining issue and defect controls, issue and defect identification and resolution, and action item tracking

·    Change control procedures, including the steps by which official company standards, policies, plans, and procedures—or any project documents—will be modified, and how any changes will be approved and validated

·    Risk control procedures, including risk categories, probability definition and impact, and probability and impact matrix

·    Procedures for approving and issuing work authorizations.

 

Organizational corporate knowledge base for storing and retrieving information:

·    Process measurement database used to collect and make available measurement data on processes and products

·    Project files (e.g., scope, cost, schedule, and quality baselines, performance measurement baselines, project calendars, project schedule network diagrams, risk registers, planned response actions, and defined risk impact)

·    Information and lessons learned knowledge base (e.g., project records and documents, all project closure information and documentation, information about both the results of previous project selection decisions and previous project performance information, and information from the risk management effort)

·    Issue and defect management database containing issue and defect status, control information, issue and defect resolution, and action item results

·    Configuration management knowledge base containing the versions and baselines of all official company standards, policies, procedures, and any project documents

·    Financial database containing information such as labor hours, incurred costs, budgets, and any project cost overruns.

 

Develop Project Charter: Tools and Techniques

 

Project Selection Methods

Project selection methods are used to determine which project the organization will select. These methods generally fall into one of two broad categories:

Benefit measurement methods that are comparative approaches, scoring models, benefit contribution, or economic models.

Mathematical models that use linear, nonlinear, dynamic, integer, or multi-objective programming algorithms.

Project Management Methodology

A project management methodology defines a set of Project Management Process Groups, their related processes and the related control functions that are consolidated and combined into a functioning unified whole. A project management methodology may or may not be an elaboration of a project management standard. A project management methodology can be either a formal mature process or an informal technique that aids a project management team in effectively developing a project charter.

Project Management Information System

The Project Management Information System (PMIS) is a standardized set of automated tools available within the organization and integrated into a system. The PMIS is used by the project management team to support generation of a project charter, facilitate feedback as the document is refined, control changes to the project charter, and release the approved document.

Expert Judgment

Expert judgment is often used to assess the inputs needed to develop the project charter. Such judgment and expertise is applied to any technical and management details during this process. Such expertise is provided by any group or individual with specialized knowledge or training, and is available from many sources, including:

Other units within the organization

Consultants

Stakeholders, including customers or sponsors

Professional and technical associations

Industry groups.

 

October 23, 2008 Posted by | Project Initiation, Project Management, Scope Management | , , | Leave a comment

Identifying Risks in Your Project

All projects have risks. It is the job of the Project Manager to identify these risks as part of the Risk Management Planning Process. Risk Identification determines which risks might affect the project and documents their characteristics. Participants in risk identification activities can include the following, where appropriate: project manager, project team members, risk management team (if assigned), subject matter experts from outside the project team, customers, end users, other project managers, stakeholders, and risk management experts. While these personnel are often key participants for risk identification, all project personnel should be encouraged to identify risks. I worked on a project where we used several of these techniques. I will point those out to you in the following sections.

 

Risk identification is an integrative process. The frequency of iteration and who participates in each cycle will vary from case to case. The project team should be involved in the process so that they can develop and maintain a sense of ownership of, and responsibility for, the risks and associated risk response actions. Stakeholders outside the project team may provide additional objective information. Especially important is the risk tolerance of the Stakeholders. This is invaluable information in Risk Planning.

 

The Risk Identification process usually leads to the Qualitative Risk Analysis process. Alternatively, it can lead directly to the Quantitative Risk Analysis process when conducted by an experienced risk manager. On some occasions, simply the identification of a risk may suggest its response, and these should be recorded for further analysis and implementation in the Risk Response Planning process.

 

Documentation Reviews

A structured review may be performed of project documentation, including plans, assumptions, prior project files, and other information. The quality of the plans, as well as consistency between those plans and with the project requirements and assumptions, can be indicators of risk in the project.

 

Information Gathering Techniques

I worked on a project where we spent three days planning the project. We engaged several experts in our technology to help us with the Information Gathering Techniques. This helped the project a lot since we (the project team) were not experts at the time of the project. They were very helpful in the brainstorming and Delphi techniques. During each following phase of the project, the Risk list should be looked at to see if any further risks have been identified.

 

Examples of information gathering techniques used in identifying risk can include:

 

·    Brainstorming. The goal of brainstorming is to obtain a comprehensive list of project risks. Our project team performed the brainstorming with a multidisciplinary set of experts not on the team. Ideas about project risk are generated under the leadership of a facilitator. Categories of risk such as a risk breakdown structure can be used as a framework.  (see earlier post) Risks are then identified and categorized by type of risk and their definitions are sharpened.

·    Delphi technique. The Delphi technique is a way to reach a consensus of experts. We used Project risk experts as well as Technology experts to participate in this technique anonymously. A facilitator uses a questionnaire to solicit ideas about the important project risks. The responses are summarized and are then sent back to the experts for further comment. Consensus may be reached in a few rounds of this process. The Delphi technique helps reduce bias in the data and keeps any one person from having undue influence on the outcome.

·    Interviewing. We also interviewed experienced project participants, stakeholders and subject matter experts to identify risks. Interviews are one of the main sources of risk identification data gathering.

·    Root cause identification. This is an inquiry into the essential causes of a project’s risks. It sharpens the definition of the risk and allows grouping risks by causes. Effective risk responses can be developed if the root cause of the risk is addressed.

·    Strengths, weaknesses, opportunities, and threats (SWOT) analysis. This technique ensures examination of the project from each of the SWOT perspectives, to increase the breadth of considered. Our project team used this technique to more fully examine the risks that had been identified.

·    Checklist Analysis. Risk identification checklists can be developed based on historical information and knowledge that has been accumulated from previous similar projects and from other sources of information. This means you have to record project information at the end of the project to build the historical database. The lowest level of the risk breakdown structure can also be used as a risk checklist. While a checklist can be quick and simple, it is impossible to build an exhaustive one. Care should be taken to explore items that do not appear on the checklist. The checklist should be reviewed during project closure to improve it for use on future projects.

·    Assumptions Analysis. Every project is conceived and developed based on a set of hypotheses, scenarios, or assumptions. Assumptions analysis is a tool that explores the validity of assumptions as they apply to the project. It identifies risks to the project from inaccuracy, inconsistency, or incompleteness of assumptions.

·    Diagramming Techniques. Risk diagramming techniques may include:

o   Cause-and-effect diagrams. These are also known as Ishikawa or fishbone diagrams, and are useful for identifying causes of risks. We used these frequently in projects.

o   System or process flow charts. These show how various elements of system interrelate, and the mechanism of causation. Seeing the flow sometimes triggers someone to identify a risk that may have slipped through the cracks.

o   Influence diagrams. These are graphical representations of situations showing causal influences, time ordering of events, and other relationships among variables and outcomes.

 

You can never spend too much time in identifying risks. After the list is made, qualitative and quantitative analysis is done to figure out which risks you spend time and/or money on. Murphy’s law is always a good one!

October 13, 2008 Posted by | Project Management, Risk Management | , , , , , , | Leave a comment

Risk Breakdown Structure (RBS)

When doing Risk Management Planning, one input you need is a Risk Breakdown Structure. The model is similar to the Work Breakdown Structure. It may change during the Risk Management Planning Process. Here is an example Risk Management breakdown:

 

  • Technical
    • Requirements
    • Technology
    • Complexity
    • Quality
    • Performance
  • Management
    • Resources
    • Company Vision
    • Capital
  • Organizational
    • Dependencies
    • Budget
    • Prioritization
  • External
    • Contractors
    • Vendors
    • Customer
  • Project Management
    • Estimating
    • Planning
    • Controlling
    • Communication

 

Risk Breakdown Structures will vary between projects. One benefit of doing one is to remind those people engaged in the Risk Identification process of areas to think about. It will also be an input to Qualitative Risk Analysis where probabilities and impacts are assigned.  The impacts can be numerical or High, Medium, Low.

 

Risks are then prioritized according to their potential implications for affecting the Project’s success. Other things to take into account are stakeholder’s risk tolerance levels, reporting formats and how you will track the risks. The next step in the process will be Risk Identification.

October 11, 2008 Posted by | Project Management, Risk Management | , | 10 Comments

A Successful Project Schedule

 

Project scheduling has always seemed to be somewhat of an art. Actually, there are a lot of logical steps that go in it. If I am the Project Manager, I have several tricks I always use to ensure that I do no bring my project in late or over budget. Here is my top list of scheduling tricks:

 

·         First, let’s assume we have a solid signed off Scope Statement Requirements document and the project is all set to go.

·         I make sure I know everyone participating in my projects and build relationships with them. If they are contributing to the schedule, this gives me an idea of what their ability level is and how well they can estimate their work. In any case, I keep a 20% management reserve to use as a cushion to give myself some wiggle room in the schedule when Murphy’s Law kicks in. For each individual, I know whether they under or over estimate and adjust accordingly. If I happen to have a person I don’t know well enough yet, I pad their estimates.

·         I schedule higher level architects or technical leads at 60% utilization because I know they will be pulled in to help the more junior engineers or to meet with upper management. For junior engineers, I schedule their time at 80% utilization to allow for sick days, vacations and meetings. I also make everyone use a Work Breakdown structure with the largest work package being 40 hours. I have the whole team review the WBS before I start the next steps in creating the schedule.

·         Note that the cost of a more senior engineer is higher and must be taken into consideration in the schedule. You may have a time when you have to make a tradeoff of cost vs. time.

·         Each element of the project scope, as defined in the WBS, must be supported by an activity, or activities, that will result in the completion of that part of the project scope. Activities must be described uniquely, have any assumptions listed and if there are known risks list them as well.

·         Once the activity list is defined, the order in which the activities will be performed must be determined and recorded. This is called activity sequencing. Things such as holidays, vacations, etc. must be taken into account at this step.

·         The resources required to complete each activity—including their availability and productivity—should be considered. I never estimate work for someone else. I always include the team in the estimating and sequencing. This gives a sense of buy-in to the schedule.

·         I use Microsoft Project Server as my scheduling tool to assemble the schedule model and provide the means of adjusting various parameters and components that are typical in a modeling process. It is a powerful tool that allows me to do what if analysis, critical path analysis and make changes on a daily basis. It allows me to schedule tasks as finish-to-start, finish-to-finish etc. depending on what is best for the project.

·         It also allows me to add lags and leads between activities.  I apply the resources using individual resource utilization percentages.

·         I add constraints where logic (precedence relationships with other activities) alone is not adequate to meet the project requirements.

·         I capture a specific schedule as a baseline or target schedule for the project. I may have a new baseline if certain factors dictate the need.

·         I use earned value analysis and trending analysis which are all easily done with Microsoft Project.

 

The key is to keep on top of the schedule every day and communicate to all the team members and stakeholders often (the communications are defined in the Communications Plan which is part of the overall Project Plan). If you catch an issue as soon as it happens, you have the tools to do various scenarios to get back on track. It is also important to publish the schedule or have it available to anyone can see it at any time. If you follow these guidelines you will have a successful project.

October 9, 2008 Posted by | Project Management, Schedule Management | , , , , | Leave a comment