Project Management Process - Phase 1 - Initiating - Identify Project Sponsor (#3 in the Hut Project Management Process) By John

Filicetti
Description Organizations attempt to accomplish many things at the same time with limited resources. Competing demands make it difficult for project teams to get management attention and commitment of resources needed for their projects to succeed. The role of the project sponsor is to:

Ensure timely decision making Advocate for needed resources Overcome organizational conflicts and barriers to project performance Responsible for appointing and coaching the project manager.

This requires that the sponsor be a member of the top management team of the performing organization with the ability to make key decisions and influence key stakeholder groups. Steps

Templates

Identify the member of management, in the performing organization, with the greatest stake in the project outcome Make sure the candidate has a track record of success sponsoring similar projects Check with candidate to ensure availability and commitment to the project Get concurrence among members of the management team Announce sponsorship to key project stakeholders.

Meeting Report

Owner of This Step

Corporate Governance Committee Other Corporate/Divisional/Department Management and other Resources as necessary

The Project Sponsor/Project Director is responsible for:

Ensuring an appropriate project or programme management framework is in place, incorporating the Gateway review process if required. Preparing the project brief, Project Initiation Document (or equivalent) and business case Appraising options and submitting for approval Securing resources and expertise from the client organisation as required, for example, appointing professional advisers to support the project sponsor role Co-ordinating and directing end user input Co-ordinating value management strategy Controlling changes following approval Determining and managing risks to the project Managing the project budget, including risk allowance Acting as sole point of contact with project manager Co-ordinating and fostering teamwork Managing the project managers performance of delegated responsibility Establishing formal reporting arrangements on project progress Defining criteria for control and management of the project Assisting the project manager in the resolution of problems

Receiving and reviewing detailed reports on the project from the project manager Ensuring the project manager receives departmental decisions on time Establishing with the project manager a common approach to major issues that arise Establishing a mechanism to ensure regular dialogue with contractors to promote problem solving, teamworking and risk-sharing

Primary Project Sponsor Responsibilities By Michele Berrie, Queensland University of Technology

Following is a list of the main responsibilities of the project sponsor:

Be chief champion of the project Have accountability for the project and ongoing accountability for the outcomes Chair the project steering committee Advocate the project internally and externally Facilitate and support policy and funding recommendations Provide overview and direction for the project Resolve issues identified by the project manager when requested (and agreed) Support the project manager in carrying out the project Monitor the project budget Monitor project risk Ensure that deliberations of the project are adequately recorded and available to appropriate parties

Sample Roles and Responsibility Matrix By Tom Carlos (PMP) Project Sponsor

Reports to the Director. Provides written status updates as required. Provides direction and responsible to oversee the activities of the project. Maintains authority and responsibility for the project once it has been approved by the Steering Committee. Reports to the Project Sponsor. Manages daily activities of the project. Provides weekly updates. Oversees working groups and provides direction to team members. Responsible for the delivery of the project. Formed to support the efforts of the project. Consists of key stakeholders, from the various divisions affected by the project, who understand how the various business units work. Provide information and input regarding how the organizations and its processes work. Identify and analyze problems. Meet on weekly basis and complete tasks as needed.

Project Manager

Working Group(s)

Authority Matrix By SmartDraw.com An authority matrix divides tasks and responsibilities for a project.

Typical Uses Project managers can use an authority matrix to describe what tasks each team member is working on, what decisions they are responsible for making, and which team members are providing support for each task. Best Practices

Determine key tasks and decisions. Make a list of key tasks and crucial decisions for your project. Create a list of key team members. Make a list of key team members. Also remember to include in your matrix people outside your immediate department who may also have responsibilities or provide support and contribute to making decisions. Fill in the table. Complete the matrix by noting who is responsible for completing each task and who is involved in making each decision. Analyze. The matrix should make clear potential bottle necks in the project as well as point to potential cross-reporting issues and conflicts.

Establishing Your Project Management Authority By H Mingail Its been a tough climb to your project management position. How do you establish your authority and inspire respect? What must be done to influence project results and growth and make your stay long and productive? The Predecessor: To begin the style of your predecessor determines how comfortably you settle in. The greatest challenge falls on the shoulders of a company insider who succeeds a strong predecessor. In this case, imitation by the new manager will seem inadequate, at worst foolish. An outsider who follows such a leader has slightly greater chances at being successful. The insider of a weak predecessor should immediately try to win over the supporters of the old regime. The outsider who takes over from such a manager has more favourable chances to start afresh and win a loyal following. The Honeymoon: With any management inauguration, a honeymoon period exists. During this time the incumbent is virtually exempt from criticism. For this reason, the new manager should use this time to establish authority and perhaps introduce changes. To emerge in a positive light once the honeymoon concludes, the manager should secure an understanding of the organizations finances. Finding and gaining control of the groups purse strings should be a priority. The Chart: Organizational charts depict positions together with authority and responsibility. These charts should be scrutinized to calculate the proper types and levels of contact. For example, if the company structure renders the manager to be a mere figurehead, negligible authority exists. Subordinate Types: In most organizations, subordinates can be divided into four groups: personal assistants, staff, subordinate managers and the rank and file. The larger the organization the more layers exist. A. Personal Assistants: These individuals must remain under the direct and exclusive control of the manager. They must also be restrained to ensure that they do not wield authority over staff and subordinate managers. B. Headquarters Staff: These staff are responsible not only to the manager but also for dispersing information and advising subordinate managers. Major staff officials should be unequal in rank, pay and influence to keep the organization in a state of positive conflict. Staff officials should be constrained from assuming too much responsibility. Regular meetings should be held between these individuals and the manager. C. Subordinate Managers: These individuals should be encouraged to assume as much responsibility as possible. Giving this group of subordinates greater autonomy, inspires their sense of commitment. As their commitment and contribution is reinforced, so too is their authority. Be cautious. Authority should be delegated to subordinate managers if (a) the manager is in control of the organizations finances (b) department performance can be objectively measured (c) the subordinate manager is not a contender for the top position. D. Rank and File: The manager has little direct contact with this group. However, each and every individual of this group should feel that the manager is their ultimate guarantee of justice. There should be in place a procedure whereby any individual can communicate with the top if the need arises. Subordinate Conversations: Subordinates initiate most conversations with managers. However, the boss launches most of the activity from these conversations.

Most subordinates prefer to minimize their contact with their manager. Others expand connections with their manager. These people are either insecure about exercising their autonomy or feel they gain by cultivating a close affiliation. Wise managers will not count too heavily on the loyalty of subordinates. They will enjoy rather than be overwhelmed by expressions of devotion. During performance appraisals they should carefully limit how this is weighed. Third Parties: The introduction of a third party into the superior and subordinate relationship, transforms the dynamics of communication. Any third party, whether a subordinates peer or a superiors peer, decreases candid communication. The intensity of the effect varies according to the identity of the third party. In order to inhibit this effect, managers should rely upon increased one-to-one communication with the subordinate. Coalitions: Groups consisting of three parties quickly generate combinations of two against one. Pairing off is called a coalition. Groups of three are triads. Coalitions may take various forms. In the case of a rebellious type of coalition, two subordinates may organize to dominate a manager. A so-called improper coalition would find a manager and a subordinate dominating another subordinate. At the same time, the manager would dominate the subordinate with whom he or she forms a union. Effective management strives to prevent these type of coalitions from forming. Reasoned thinking and behaviour rather than gang influence should win progress. Crisis Management: Its inevitable. No matter how long or how well a manager may have done the job or exercised, the occasional crisis will rear its menacing head. In hard times it is essential that a manager follows a sequence of crisis activities:

Recognize the crisis; Be present on the scene; Recruit a crisis council; Mobilize resources; Enact a plan; Announce the outcome; Distribute awards.

Very importantly, react positively when you hear that something is amiss. Thank rather than shoot the messenger of bad tidings. The Boss: A strong alliance with the boss translates into power and influence for you. Deficient boss support dooms you to struggling with your authority and eventual failure. Too much competition and conflict leads to similar unhappy ends. Empower Employees: To perform their jobs effectively, employees need authority commensurate with responsibility. Give it to them. Dont battle them for what is rightfully theirs. For example, assigning work or giving commands directly to the staff belonging to your subordinate boss, undermines the authority and effectiveness of the subordinate. Check Your Authority:

My subordinates come to me for advice and instruction. Rarely do I have to send for them on routine matters. My suggestions to subordinates are heeded. They are not misconstrued as orders. I can go anywhere within the organization without experiencing embarrassment or constraint. My closest working associates are those who are closest to me in formal authority. I am the first to hear about a new organizational problem.

My subordinates are comfortable making decisions on their own. If I have been away, I do not return to a crisis situation. My subordinates have differences over organizational policies. However, these do not lead to personal quarrels. Rank and file members of my organization seem pleased to meet with me when we unexpectedly see each other. When presiding at meetings of subordinates discussion of issues comes easily. When I attend a meeting run by one of my subordinates, it proceeds smoothly. My group has low turnover and absenteeism. When a position under me becomes available, there is considerable competition to fill it. I do not have to deal with a rebellious coalition and do not partake of a coalition myself.

For a manager to be loved and respected, the organizations program must be successful. The manager must be directly responsible for its success and must have a reputation for acts of kindness to individual subordinates. A feared and respected manager fosters a reputation for decisive action in the interests of the organization. This ability, called charisma, arouses both fear and love among followers which is called charisma. Charisma empowers the manager with vast amounts of authority.

PM Authority By Jorge Dominguez Much has been said and written about the PM authority or lack thereof. The 3rd edition of the PMBOK says that the project charter document addresses who the project manager is and his or her authority level. Is this enough for the PM? What authority are we talking about? And, what level of authority? In most organizations, the PM, literally, has very little to no authority at all. He or she, however, has all the accountability and responsibility for the final outcome of the project. Funny, isnt it? It is funny but its critical. First, the authority has to be provided in writing by someone such as the organization itself through policies, the project sponsor, or your boss. Unfortunately, this is largely ignored by most and produces devastating results for the project, and ultimately, the organization itself. Politics is one of the reasons why this is ignored; a PM cannot have so much power. The PM, and especially a PMP certified PM, has an obligation to ensure that authority is granted. This is the power needed to make things happen. Second, the authority given must have clear duties or responsibilities: this is the level of authority. In most cases, in a very political environment, the PM is provided with authority just to comply with policies and/or project management standards used by the organization but there is no clear understanding of what the duties or responsibilities are. They must be spelled out and communicated to all project stakeholders: defining the project, leading the project team, hiring/firing of team members, communicating progress status, etc. When the above is lacking it is very challenging for the PM because now you have to get results without authority. The PM will then have to have such control of the project that it can be counterproductive. The PM has to have authority and responsibilities to manage a project because at the end of the day, when the project fails, there is only one person your boss will look to for answers: you. Dont you think so? Well, I do.

Understanding Authority Levels By Thomas Cutting The purpose of authority is to accomplish the goals of a project or organization. But authority is a slippery thing. This is especially true for a consultant. On one assignment you are the program manager over several projects and the next you might be reporting to one of your former project managers. Keeping that perspective helps you refrain from abusing your power. Here are a couple of other things I have learned about authority. No Respect. Project Managers generally have no direct authority, especially in a matrix environment. The only real authority you have is either given to you or earned. Take as much as you want. Many people are willing to give up authority if you are willing to do the work that goes with it. Obviously there are limits, especially in organizations based on authority and when dealing with power hungry individuals, but in general you will find this true. The key is to pick and choose the responsibilities that will help your project be successfully. One overlooked but powerful position is meeting ownership. If you can control the agenda and minutes for a meeting you hold a strategic place. It may sound boring but deciding what is discussed and being able to steer the conversation where you want is powerful. Positional Authority. This is probably the weakest form of authority, but is usually the most abused. Its weakness comes from the fact that it isnt always deserved, doesnt necessarily come with respect and can be taken away as quickly as given. That doesnt mean it isnt useful. As a project manager, your Charter or other defining documents give you the authority to run the project. Use it with respect for individuals and it can help you move obstacles. Referent Authority. This includes things like your charming character and charisma but it also includes authority based on a higher level manager. Essentially this amounts to name dropping but it is effective. I find that if an email starts by saying the VP of Finance asked you to follow up on something it will probably get a faster response than if just ask nicely. Coercive and Reward Authorities. The use of punishment and positive reinforcement are two types of authority that can be effective. The possibility of a better project, more pay or a new job title can encourage people to put in extra effort. Demoting or taking privileges away can correct help bad behavior or encourage people to seek employment elsewhere. The problem is that these only work until youve ticked your team off or you no longer have anything to offer. Expert Authority. If you can earn the respect of your team and management you have the highest level of authority anyone can achieve. No, Im not talking about the respect that Al Capone had by roughing people up. Respect is earned by successfully managing projects and treating people right. Real respect makes people want to work for you because of your abilities and it makes your team want to you to be successful. Whatever authority you are wielding, remember to use it for good and not evil.

Referent Authority. This includes things like your charming character and charisma but it also includes authority based on a higher level manager. Essentially this amounts to name dropping but it is effective. I find that if an email starts by saying the VP of Finance asked you to follow up on something it will probably get a faster response than if just ask nicely. Coercive and Reward Authorities. The use of punishment and positive reinforcement are two types of authority that can be effective. The possibility of a better project, more pay or a new job title can encourage people to put in extra effort. Demoting or taking privileges away can correct help bad behavior or encourage people to seek employment elsewhere. The problem is that these only work until youve ticked your team off or you no longer have anything to offer. Expert Authority. If you can earn the respect of your team and management you have the highest level of authority anyone can achieve. No, Im not talking about the respect that Al Capone had by roughing people up. Respect is earned by successfully managing projects and treating people right. Real respect makes people want to work for you because of your abilities and it makes your team want to you to be successful. Whatever authority you are wielding, remember to use it for good and not evil. If the project is not strategically important, why are you wasting time trying to accomplish it? In reality, if the project is important enough to the organization, you have the authority to do just about anything you need to do. (You need the self esteem to do what you need to do.) But if the project is not important enough to the organization, you can never get enough authority to do what you need to do. Even if the project is strategically important, you may need to use your influencing skills to get done what you need. I attempt to lay the foundation for influence across the organization before I need it. Then when I need help, I can enroll other people to help me push my agenda forward. Ive used sales, service, operations, and marketing people to help me move the project forward. If youve been working in the organization for a while, youve probably built influence. If you havent paid attention to your relationships (aka politics), do so. Politics is not a dirty word. Politics is the way you can accomplish things in organizations, especially if you dont have the resources to do it all yourself. I see responsibility vs. authority differently than other people do. I see it more as responsibility to take authority, rather than wait for someone to give me the authority. Let me know what you think.

PM Authority By Jorge Dominguez Much has been said and written about the PM authority or lack thereof. The 3rd edition of the PMBOK says that the project charter document addresses who the project manager is and his or her authority level. Is this enough for the PM? What authority are we talking about? And, what level of authority? In most organizations, the PM, literally, has very little to no authority at all. He or she, however, has all the accountability and responsibility for the final outcome of the project. Funny, isnt it? It is funny but its critical. First, the authority has to be provided in writing by someone such as the organization itself through policies, the project sponsor, or your boss. Unfortunately, this is largely ignored by most and produces devastating results for the project, and ultimately, the organization itself. Politics is one of the reasons why this is ignored; a PM cannot have so much power. The PM, and especially a PMP certified PM, has an obligation to ensure that authority is granted. This is the power needed to make things happen. Second, the authority given must have clear duties or responsibilities: this is the level of authority. In most cases, in a very political environment, the PM is provided with authority just to comply with policies and/or project management standards used by the organization but there is no clear understanding of what the duties or responsibilities are. They must be spelled out and communicated to all project stakeholders: defining the project, leading the project team, hiring/firing of team members, communicating progress status, etc. When the above is lacking it is very challenging for the PM because now you have to get results without authority. The PM will then have to have such control of the project that it can be counterproductive. The PM has to have authority and responsibilities to manage a project because at the end of the day, when the project fails, there is only one person your boss will look to for answers: you. Dont you think so? Well, I do.

Project Review = Responsibilty By Elizabeth Harrin If you ask a colleague to run a project review for you, chances are at some time they will ask you to return the favour. They will look to you for an unbiased, clear and concise healthcheck of their project. Its quite a responsibility but not one to be afraid of. The objective of a project review is to provide an independent overview of a project and help the project manager better understand where they are facing challenges. Reviews are often scheduled as part of the normal project planning process. Alternatively, one might be arranged because the project manager feels they are starting to lose their grip on the project and could do with a second pair of eyes to help bring things back on track. This is the first thing to understand when you are asked to review a project: is the project already in trouble or is the review just routine? The answer will help you better prepare for the review. The second thing to establish is what the project manager wants to achieve from the review. The project manager should have an idea about what they want the review to cover. Encourage them to focus on a few key elements to give the review a structure. To help you answer the fellow project managers key concerns you will need to look through the project documentation and talk to the project manager and perhaps members of his/her team. You dont need to be an expert in the subject matter: the review is to look at how the project is being managed, not if Product X will sell well or whether the IT users have actually asked for what they need. Focus on how you can help the project manager run this project more efficiently. Do they have signed-off documentation? Is the plan up to date? Are their risks being managed effectively? You can prepare a lot of this in advance of your meeting with the project manager, and this pre-work will also help you develop a list of structured questions to ask, based on areas where you need more clarification. Plan adequate time for the review. Even during a long review you will probably not have time to go sufficiently in depth to produce any recommendations of value. Theres another reason to avoid long reviews too: Normally there are one or two major aspects of a project that if improved, would give disproportionate benefits to future projects. Identifying these aspects is a much better use of your time than coming up with a list of actions that will make a marginal difference to the quality of the project. You will need to establish a balance between what is too long and what is too short to cover the key areas. The more time that can be given to a project review, the more relaxed and creative the team can be in understanding what has happened during the project and how they might improve in the future. Before you meet the project manager, agree in what format the output will be and who will receive it. In most cases your primary responsibility is to the project manager. Encourage him/her to share the review results with his/her team and hierarchy. These results can be presented in a structured format or more informally. Finally, make sure your report includes practical, actionable actions. Provide your feedback in a constructive way: there is no point saying that the change management process is not being applied properly unless you also explain what needs to happen to improve the way the project manager is using that process. Help the project manager understand your recommendations and allocate an owner and date to each task. Once the review is over, the report produced and the results discussed, you can sit back, and watch that project improve, knowing that some day, someone will do the same for you.

5 Steps to Build Stronger Communication and Understanding By Chris Anderson Did you know that you should always create a process map for every procedure or system of procedures that you develop? And did you know that, like a table of contents, this will create stronger communication and better understanding in your organization? How do you do this? Identify Core Processes Last time, we followed the money trail and identified your business core processes. We discussed where to best start a change in one of those core processes. And we introduced the technique of producing a process map. So this week, lets take a further look at how to create a process map and see how it creates knowledge to benefit you and your organization. Use Process Map as Communication Tool A process map is a flow diagram of the primary processes within an organization. It very specifically shows you both who and what is involved in a process, as well as the requirements for that process to be effective. The primary goal is to use the map as a communication tool. It is to show the sequence of interactions of the elements involved in the process. And so process maps are drawn and used by organizations to achieve several benefits: Increase process understanding Clarify process boundaries, ownership and effectiveness measures Identify process sequences Isolate core processes, bottlenecks and opportunities for improvement Clarify the interaction of Customer, Supplier, Management and Operations processes Provide a tool for training and discussion In other words, a process map details what happens first, second and third in a process. It shows what happens in each step along the way. And this is drawn in graphical form for easier communication and understanding. This type of map shows the big picture of 10-20 core processes within an organization. The map also shows the critical elements within each section and its importance within the whole system. And these sections, or bands, are what relate the processes to each other AND to the outside suppliers and customers. Link Suppliers and Customers Although there are several ways to draw a process map, the basic diagram is typically constructed in four bands. And these four bands link together Customers, Primary Processes, Secondary Processes and Suppliers. You improve effectiveness by showing the specifics of a process. And sometimes weve learned the hard way that the development phase of a project or a process is far more expensive than the planning phase. And so by thinking through and perfecting your processes beforehand, you decrease waste in development time. With a detailed process map, you identify and decrease such waste wherever it occurs in the process. Here are a few key points to keep in mind while process mapping: Identify core processes to support mission and goals Determine how to create value for the customer throughout the process Map ownership and performance metrics along with the process Engage your people in process mapping to define problems and solutions Now, lets break down the process map even further. Define Steps of the Process Weve just defined the big picture process map as a sequence of interactions of multiple processes. These multiple processes consist of multiple steps. As weve discussed, the benefits are better communication and understanding and a decrease in waste. And this offers a great big picture view of your organizations processes. But

When you go to write your organizations procedures, you need more detail. Youll need a method to define the sequence of interactions of each step. And you do this with a procedure map. Heres an example of a typical procedure map: With this refined procedure map, you can see the steps that go into an organizations competency process, including the suppliers and customers for each of those steps. This is also called the SIPOC method. This method identifies the Suppliers of the specific data used as an Input for the Process to create Outputs for the Customer. The map also gives you both effectiveness and performance criteria for this process owner(s). With such measurement criteria, you set the mark for continuous improvement of the process. And so by creating a procedure map, you will further increase communication and understanding within your organization. Procedure maps become a strong tool in training, either to familiarize new employees to their jobs or to increase efficiency and performance with current employees. Communicate, Understand and Apply Knowledge Both process and procedure maps are crucial in an organization. And so as a rule of thumb, never develop a procedure or system of procedures without first creating a process and procedure map. Acting like a table of contents, a process map helps organize the chapters of a complex book in a way that this knowledge can easily be communicated, understood and applied.

Understanding Authority Levels By Thomas Cutting The purpose of authority is to accomplish the goals of a project or organization. But authority is a slippery thing. This is especially true for a consultant. On one assignment you are the program manager over several projects and the next you might be reporting to one of your former project managers. Keeping that perspective helps you refrain from abusing your power. Here are a couple of other things I have learned about authority. No Respect. Project Managers generally have no direct authority, especially in a matrix environment. The only real authority you have is either given to you or earned. Take as much as you want. Many people are willing to give up authority if you are willing to do the work that goes with it. Obviously there are limits, especially in organizations based on authority and when dealing with power hungry individuals, but in general you will find this true. The key is to pick and choose the responsibilities that will help your project be successfully. One overlooked but powerful position is meeting ownership. If you can control the agenda and minutes for a meeting you hold a strategic place. It may sound boring but deciding what is discussed and being able to steer the conversation where you want is powerful. Positional Authority. This is probably the weakest form of authority, but is usually the most abused. Its weakness comes from the fact that it isnt always deserved, doesnt necessarily come with respect and can be taken away as quickly as given. That doesnt mean it isnt useful. As a project manager, your Charter or other defining documents give you the authority to run the project. Use it with respect for individuals and it can help you move obstacles. Referent Authority. This includes things like your charming character and charisma but it also includes authority based on a higher level manager. Essentially this amounts to name dropping but it is effective. I find that if an email starts by saying the VP of Finance asked you to follow up on something it will probably get a faster response than if just ask nicely. Coercive and Reward Authorities. The use of punishment and positive reinforcement are two types of authority that can be effective. The possibility of a better project, more pay or a new job title can encourage people to put in extra effort. Demoting or taking privileges away can correct help bad behavior or encourage people to seek employment elsewhere. The problem is that these only work until youve ticked your team off or you no longer have anything to offer. Expert Authority. If you can earn the respect of your team and management you have the highest level of authority anyone can achieve. No, Im not talking about the respect that Al Capone had by roughing people up. Respect is earned by successfully managing projects and treating people right. Real respect makes people want to work for you because of your abilities and it makes your team want to you to be successful. Whatever authority you are wielding, remember to use it for good and not evil.

Project Management Role and Responsibilities By Siraj Qureshi

To deliver a solution within project constraints, strong project management skills are essential. Project management is a process that combines a set of skills and techniques to address the following tasks:

Integrate planning and conduct change control Define and manage the scope of the project Prepare a budget and manage costs Prepare and track schedules Ensure that the right resources are allocated to the project Manage contracts and vendors and procure project resources Facilitate team and external communications Facilitate the risk management process Document and monitor the teams quality management process makes the final decision on the issue by transitioning into the role of decision leader to enable the project to continue.

Program management makes the decision with the goal of meeting the customers requirements and delivering the solution within the constraints. After the decision is made, the team returns to operating as a team of peers.

Project Manager Responsibilities By Michele Berrie, Queensland University of Technology

Manage the project taking into account integration across all areas. Engage with stakeholders. Develop Project Plan. Direct project resources. Monitor and manage the project schedule. Monitor and manage the project budget. Monitor and manage the project risk. Deal with operational issues. Organise steering committee meetings, including ensuring that minutes will be taken. Report to the steering committee, raising strategic issues. Prepare Project Status Reports and Project Change Requests for the steering committee. Ensure project meets requirements and objectives . Manage project team members. Negotiate and resolve issues as they arise across areas of the project and where they impact on other activities, systems and projects. Look after the interests of the project team. Organise and chair project reference group meetings, as appropriate. Communicate project status to project sponsor, all team members, and other relevant stakeholders and involved parties . Maintain project documentation.

Specific Responsibilities of the Project Manager By The Office of Government Commerce - OGC, UK
The Project Manager operating within agreed reporting structures (see figure below) is responsible for:

Designing and applying an appropriate project management framework for the project (using relevant project standards) incorporating the Gateway review process if required Managing the production of the required deliverables Planning and monitoring the project Adopting any delegation and use of project assurance roles within agreed reporting structures

Preparing and maintaining the Project Plan (or Project Execution Plan), Stage and Exception Plans as required Manage project risks, including the development of contingency plans Liaison with programme management (if the project is part of a programme) and related projects to ensure that work is neither overlooked nor duplicated Overall progress and use of resources, initiating corrective action where necessary Change control and any required configuration management Reporting through agreed reporting lines on project progress through Highlight Reports and stage assessments Liaison with appointed project assurance roles to assure the overall direction and integrity of the project Adopting technical and quality strategy Identifying and obtain any support and advice required for the management, planning and control of the project Managing project administration Conducting end project evaluation to assess how well the project was managed [nb 'post project' is different from 'end of project'] and preparing and end-project report Preparing a Lessons Learned report Preparing any follow-on action recommendations as required

Project Management Role and Responsibilities By Siraj Qureshi

To deliver a solution within project constraints, strong project management skills are essential. Project management is a process that combines a set of skills and techniques to address the following tasks:

Integrate planning and conduct change control Define and manage the scope of the project Prepare a budget and manage costs Prepare and track schedules Ensure that the right resources are allocated to the project Manage contracts and vendors and procure project resources Facilitate team and external communications Facilitate the risk management process Document and monitor the teams quality management process

makes the final decision on the issue by transitioning into the role of decision leader to enable the project to continue.

Program management makes the decision with the goal of meeting the customers requirements and delivering the solution within the constraints. After the decision is made, the team returns to operating as a team of peers.

The responsibilities of the Program Manager are:

Planning and designing the programme and proactively monitoring its overall progress, resolving issues and initiating corrective action as appropriate; Defining the programmes governance arrangements; Quality assurance and overall integrity of the programme - focusing inwardly on the internal consistency of the programme; and outwardly on its coherence with infrastructure planning, interfaces with other programmes and corporate technical and specialist standards; Managing the programmes budget on behalf of the SRO (Senior Responsible Owner), monitoring the expenditures and costs against delivered and realised benefits as the programme progresses; Facilitating the appointment of individuals to the project delivery teams; Ensuring that the delivery of new products or services from the projects is to the appropriate levels of quality, on time and within budget, in accordance with the programme plan and programme governance arrangements; Ensuring that there is efficient allocation of common resources and skills within the project portfolio; Managing third party contributions to the programme; Managing the communications with all stakeholders; Managing both the dependencies and the interfaces between projects; Managing risks to the programmes successful outcome; Initiating extra activities and other management interventions wherever gaps in the programme are identified or issues arise; Reporting progress of the programme at regular intervals to the programme director; On large and complex projects it may be appropriate to appoint other individuals to support the Programme Manager for some of the particular responsibilities listed above, for example a risk manager, a communication manager or a financial manager.

Duties of the Project Manager During All Phases By John Filicetti

Following is a list of the duties of the Project Manager during all phases: Initiating, Planning, Implementing, and Closing.

All meetings require a Meeting Report to be completed and filed in the project workspace Manages Change Control, Issues escalation and resolution, Schedule, Costs, and Resources Manages the collaborative project workspace environment for the program or project and updates the workspace on a timely basis Responsible for having most current project documents Conducts team building and team development activities Establishes reward and recognition systems Monitors & acknowledges performance Increases team member proximity if possible Provides coaching, mentoring, and assistance to team members as needed Works closely with functional managers to resolve team members workload conflicts Ensures needed training is provided to accomplish project objectives Identify and resolve conflicts

Duties of the Project Manager During the Initiating Phase By John Filicetti

All meetings require a Meeting Report to be completed and filed in project folder. The best way to use the Meeting Report is to fill in the meeting information, fill in the agenda, and send the Meeting Report to the meeting attendees. During or after the meeting, fill in the minutes with any assignments noted; distribute the final document to the team and post in the project folder. PM participates in project estimation and pricing estimation activity. PM ensures the SOW or Project Charter is properly completed and ready for submission PM creates the RAIDCBT (Risk, Action Item, Issues, Decisions, Change, Business Process, and Training Needs). The risk assessment and risk management plan is completed and updated in the RAIDCBT. All issues and action items are tracked, escalated, and managed to resolution by the PM. PM distributes blank Change Control form to the Client and project team. Creates Project Status Report on a regular basis, distributes the report to stakeholders, and posts the report to the project workspace.

Duties of the Project Manager During the Planning Phase By John Filicetti

Ensures the Requirements Survey is properly completed and filed in the project workspace PM creates Project Contact List. PM works with project team to create the Project Schedule. PM and project team creates the Project Management Plan including: Project Goal, Objectives, Assumptions, Constraints, and Approach. The Project Budget and Cost Plan. The Project Staffing Plan, Organization Chart, and Roles & Responsibilities. The Quality Plan. The Communications Plan. The Change Management Plan. The Procurement Plan. The Training Plan if necessary PM creates Project Summary. PM works with project team to create the necessary planning and design documents and gain signoff by the client. PM ensures the distribution of the documents to project team members and stakeholders. PM creates Project Status Report on a regular basis, distributes the report to stakeholders, and posts the report to the project workspace.

Duties of the Project Manager During the Implementing Phase By John Filicetti

Ensure Client notifies end-users of all deployment dates. Creates Project Status Report on a regular basis, distributes the report to stakeholders, and posts the report to the project workspace. PM assigns tasks to resources and gathers information from the team when updates are made. PM approves all work and reviews/manages project schedule updates. (Note: It is a good idea to go over weekly tasks with team on Monday and have review of week with team on Friday.) PM meets with other PMs and Resource Managers to review resource allocation and utilization. PM chairs all Status Meetings: PM fills out Meeting Report for all meetings and distributes to team as agenda prior to meeting along with current RAIDCBT and Project Schedule. PM updates Meeting Report with minutes during meeting and distributes to Client PM and project team. Discuss weeks goals. Discuss week accomplishments. Review/update all open issues using RAIDCBT. Review/update items in Project Schedule. RAIDCBT is updated during the Status Meeting; the PM escalates issues and action items as needed; tracking all issues and action items to resolution. Allow time for sharing and discussion, but limit meeting to 1 hour. PM distributes all updated documents to Client PM and project team.

PM manages and tracks Project Schedule and ensures invoices are issued and all expenses tracked. PM manages Issue and Incident Escalation Process. All issues are assigned to a person and managed to resolution. PM ensures Client, project stakeholders, and team members have all documents. PM insures scope of work matches scope of agreement with client. PM manages Change Control. Any change requested by the Client will be reviewed by the PM for impact and cost and be managed through the Change Control process. PM directs the creation and testing of the Deployment and Contingency Plans. PM reviews teams work for quality ensuring scope of work matches scope of agreement with client.

Duties of the Project Manager During the Closing Phase By John Filicetti

PM creates Closeout Form to capture Lessons Learned and Best Practices PM ensures all project documents are in the project workspace prior to closeout PM chairs the Closeout and Review meeting PM plans for and manages the project celebration PM completes a performance feedback for every team member, reviews it with the team member, and supplies it to the team members manager PM plans for and manages the project celebration. PM ensures all billing and administrative tasks are complete

Project Management Pitfalls By Alexander Hankewicz Through the implementation of enterprise wide systems many organizations have experienced success in transforming their enterprise from a reactionary task driven environment into a modern proactive, cohesive organization which can provide visibility to Senior Management and to customers and suppliers alike. ERP implementations are usually large, complex projects, involving large groups of people and other resources, working together under considerable time pressure and facing many unforeseen developments. Not surprisingly, many of these implementations turn out to be less successful than originally intended. The ERP system implementation in itself is not meant as a panacea for all of the companys ills, but should be the logical starting point from which to document business processes to define and develop strategies towards managing the organizations resources in both a structured, strategic and collaborative framework.

Shifting Paradigms
In a recent study published by CIO Insight Magazine dated July 2006: Whats the Value of IT? At Many Companies, Its Just Guesswork a. b. c. I.T. Professionals responded that nearly 70% of Companies with less then $100, Million U.S.D. annual sales stated: The Pressure to place a dollar value on intangible or soft benefits from I.T. investments had increased in recent years. In the same survey that 83% of firms with annual sales below$500 million U.S.D. that the results of the ROI analysis usually influence I.T. investment spending. My firms CFO is demanding new and improved methods to measure that our I.T. Investment generates business value.

On the basis of this study the argument can be made that unless projects can deliver upon the stated objectives within the project deliverables and under budget then financial approval of not be likely. Furthermore the Project Manager and team have to orient their paradigms to be aligned more on a business model Beyond the technical aspects of technology deployment such as form, fit and function are related change management issues which if not managed as part of the Project Plan can threaten to derail a project in its entirety, the change management issues have become to be known as Critical Success Factors or (CSFs).

Top Ten Critical Success Factors

In a recent article by the Dutch Consulting Firm Somers & Nelson a study was authored which featured a list of over 21 Critical Success Factors compiled and further ranked by I.T. professionals in the U.S. whose firms had deployed an ERP system a year earlier Or were about to deploy an ERP system: 1. Management Support Senior Management although providing the authorization for the funding, must be seen playing an active role in providing top down leadership for the project and participate in key decisions related to the project. Senior Management also has to be viewed as a resource where the PM can turn to leverage stakeholder cooperation and a resource where by requests for resource management can be funneled. Project Team Knowledge Resources within I.T. fields are highly specialized and are scarce frequently resources are contracted for a specific period of time according to both skill set required and availability. The Project Manager has to be able to assess the relative skills sets required within and where they will be required in the project lifecycle. If resources are not available the P.M. has to be able to mentor and encourage and even teach new skills to reach the particular milestone. Interdepartmental Cooperation Most projects have a collaborative requirement and feel to them and the PM has to not only build teams but reach across other departments and conflicting schedules and constraints to generate the cooperation of the resources from other departments. The paradox being that the goal in introducing technology is to introduce business functions across several departments in a seamless fashion. Clear Goals & Objectives In the project mapping process a blueprint is defined and goes through an evolutionary process throughout the project lifecycle and as such goes through stages of identification, validation and refinement before acceptance as a business process model. Project Management The PM has to be aware of many different project management methodologies and may have to select from the particular model which is aligned to the nature of the project scope. The PM also has to have inter-personal skills which cam make decisions, motivate personnel to action and also be able to

2.

3.

4.

5.

effectively communicate with all levels of company management. Furthermore the PM must be sensitive to cultural and global differences in work ethic and management styles. 6. Management of Expectations This is an important part of activity throughout the project management lifecycle as expectations by the external vendor could be overstated or Senior Management that is not closely aligned to the project may interpret their own ideas as to what constitute an outcome. 7. Project Champion This is a role usually someone which is on the company Senior Management Team i.e. C.I.O. that not only is the senior voice and face of the project but can champion ideas and deal with concerns that are addressed by the PM and can be communicated to Senior Executive Management for resolution. 8. Vendor Support This is critical to the overall project management model and requires in-depth study as no RFP document can respond to this. The PM and team will have to consult with external users of the system and other client locations of the vendor to evaluate the level of support. Additionally the software vendor unbeknown to the RFP may choose to lower their costs by outsourcing that layer of the project to keep down their costs to optimize profits, This is critical that a stipulation be placed on the RFP which excludes the vendor to outsource that part of the mandate. 9. Vendor Selection The pivotal piece of the Project Management puzzle as this is the solution that everyone has embarked upon and the enterprise is going to align their growth and manage their resources to. Reputation of being a stable product with few releases being produced, a large network of users to refer to and a product which is scalable and does not require a great deal of customization and can be deployed and support 10. Project Communication In todays project management world where code may be written in India and supported in central America and companies have applications that are used globally. The need to communicate effectively across several levels of management ,in different time zones and to be able to manage priorities is key. In order to adhere to the Project Schedule parts of the project may be outsourced across the globe and across many different departments. To unite all these factions together is to hold a scheduled meeting that transcends as many as the time zones, this can be done using tools such as net meeting,or other telephone and visual tools where files can be shared and information across key decision makers can be shared and communicated with. The style of communicating has to also be positive and proactive as it has to always engender the spirit of cooperation and that everyone has a sense of ownership to the projects success. Dont forget, you can also check out project management software solutions and get a free shortlist by going to our PPM Evaluation Center.

The project team is collectively responsible for:

Assisting the project manager to deliver the projects objectives Within their technical expertise carrying out the elements of the project they are tasked with Providing administrative support to the project manager (this may be through the setting up and resourcing of a project support office) Advising the project manager if any risks arise that likely to affect delivery of the projects objectives and to be part of the risk reduction process Providing information for project documentation as required

Duties of the Project Team During All Phases By John Filicetti

Implement project activities outlined in Project Management Plan, Project Schedule, and Project Design under management of Project Manager Create and update project documents as called for and ensure all documents are posted to the project workspace while being created or complete Distribute documents per the Communications Plan Using the project workspace, keep Project Manager and other management informed of all project activities and issues All project team members responsible for having most current project documents from the project workspace

Finish timecards on timely basis to provide time information for Status Report and Cost Report

Project Steering Committee Responsibilities By Michele Berrie, Queensland University of Technology

Following is a list of the main responsibilities of the project steering committee:

Direct attention to the project at a strategic level. Make strategic decisions where required. Approve or kill the Project Plan . Make decisions on whether to approve requested changes in the Project Plan or kill or halt the project while the project is executing. Ensure that the relevant governance council is advised of significant project issues through the Project Portfolio Office. Provide guidance to the project manager . Review project progress and issues with the project manager regularly. Monitor the project budget: a key factor. Monitor the project risk: a key factor that is increasingly important. Resolve policy issues. Escalate issues where required.

The project boards executive (the SRO - Senior Responsible Owner) is responsible for:

Appointing the Project Sponsor/Project Director (and Project Manager, where these roles are combined) and agreeing his/her remit and delegated authority; Signing off the Project Brief and Project Initiation Document or equivalent; Agreeing all major plans; Authorising any major deviations from the agreed stage plans; Signing off the completion of each stage, including the deliverables, and giving approval to start the subsequent stage; Communicating information about the project to the organisation(s) and stakeholder groups as necessary; Ensuring that the required resources are available; Resolving any conflicts escalated by the project team, client or supplier; Agreeing the project tolerances for time, quality and cost; Providing overall strategic guidance for the project; The risk(s) associated with the project; The quality assurance for the project; Providing advice and direction to the Project Sponsor/Project Director; Approving the end project report and the lessons learned report; Ensuring that a post implementation review (or post project review) is scheduled and takes place; Resolving deviations from plans or escalating as necessary; Resolving conflicts between project team, end users and suppliers or escalating as necessary.

Rise of the Project Workforce, Chapter 8: Initiating Projects (#8 in the series Rise of the Project Workforce) By Rudolf Melik
While considerable energy and effort goes into executing and delivering projects, too many company still use informal, email-based processes to initiate projects. Instead, a corporate-wide policy and process for project initiation will ensure that the right projects are executed, that they are funded appropriately, and that there is accountability for their approval. Additionally, a project initiation process that can be audited and archived will ensure compliance with government regulations, where applicable. In some cases, project initiation can be a project unto itselfespecially if it requires a feasibility study or business case development. Project Workforce Management provides a workflow foundation that can guide the project initiation effort, whether it is a full-scale project, or a routine business process. Having a structured process within Project Workforce Management provides the benefits of: streamlining the information gathering phase; closing information gaps; integrating with CRM and other enterprise applications; reducing time spent on compliance activities; enhancing productivity; and formalizing the launch. A typical project initiation workflow consists of:

A standardized proposal, which can often be submitted using a web-based form, and ensures that all initial information is complete and distributed to the proper stakeholders. Business case review, in which the decision maker(s) can evaluate the proposal, request more information, and accept or reject it. Feasibility or readiness study, to assess the projects resource requirements and risks. Usually, the executive or manager who will be responsible for the execution of the project will manage this activity. Budget approval, to assess the monetary requirements. Usually, the COO or CFO will manage this activity. Launch, during which all planning is completed: the project plan, individual roles and responsibilities, tools and methods, reporting cycle, and other critical elements of the projects execution.

Too many projects get funded based on incomplete assumptions, false expectations, and favoritism. But a structured, workflow-based project initiation process, especially when combined with intelligent project prioritization and selection, will enhance your ability to approve, fund and plan the best projectsones that are aligned with your strategic direction.

The Specifics Of Project Risk Management By Kelly Bendall

Risk management, as the term implies, focuses on managing the risk. While the approach deals with all kinds and levels of risk, specific attention is logically devoted towards management and mitigation of risk arising from uncertainty embedded in the project. This is accomplished via a host of established strategies, deployed in a sequential manner. Risk management is an overall term, which is often sub-divided by various organisations and departments to ensure respective suitability. Examples could be a financial risk or say a legal risk. However, the term has a wider perspective and while it is not practical to cover it all here, this article follows a controlled approach and thus highlights upon the nitty-gritty of project risk management. The Process of Project Risk Management Risk management and thus project risk management is a comprehensive process aimed at risk identification, planning stages post risk identification, defining the essential activities to be undertaken, and therefore lessening of the recognised risks. While relating particularly to the project risk management perspective, activities begin by planning the risk aspect in relevance to the project under consideration. The plan is comprehensively defined to include even the most basic of tasks, essential for project completion. The idea is to plan risk management for the project. The next stage focuses on project risk identification. Risk identification is a task responsible for recognising the potential risks and naming them. A risk manager could be appointed at this stage, who would be responsible for identification, input compilation and appropriate documentation for further stages. While identifying the project risks, risks can be divided into two categories: generic risks, which are almost universally applicable; other risks, which are the specific project risks. The other crucial tasks, which ought to be conferred due attention at this stage, relate to narrowing down to the precise cause of identified risks, and working out the possible impact the defined risks would pose. What follows in the process of project risk management is the requirement to quantify the risks and the associated impact. Tools like probability, sampling and other statistical methodologies can be deployed to get precise results. Risks with these techniques can be classified in various categories, for example: impact, those requiring immediate attention, unavoidable, etc. The course to follow would vary with the categorisation. Once the risks have been identified and quantified, it is now about working out the response. Project risk management aims at deriving reasonable solutions, which could be reworking the subtasks confronted with risk and thus avoiding the risk or perhaps eliminating the risk cause. Accepting and thus providing scope for the risk is also an option. Controlling Risk A proactive approach would be to control the risk element. This is enabled by closely understanding the requirements of the project. If the requirements are well understood, chances of incorrect objective statement and related threats can be suitably controlled. To ensure specific understanding it is essential to make room for the customers requirements as well. The requirements of the project ought to be quantifiable and realistically defined. Also they must be in line with the companys overall purpose of existence. And then of course, the most important aspect is to be ready with an alternate course in case of severe threats. Conclusion Risk management and therefore project risk management is a continuous process, which begins with the project and continues throughout. It takes a careful examination of understanding whether there has been enough precaution or if more needs to be done to prevent harm occurring. All companies should have a project risk management program in place to prepare them for all eventualities. Kelly Bendall wrote the article The Specifics Of Project Risk Management and recommends you visit http://www.afaprojects.com for more information on booking a MoR Risk Management Course.

Managing Project Risks and Issues By David Viney Inherent (or Business) Risk Inherent Risk is the risk that exists in the environment around your portal project. It will tend to be unique to your organisation; its culture and politics. For example, if you have a fragmented business (either geographical or functional), then this will create a higher inherent risk of poor communication. Project (Specific) Risk Project Risk is the risk specific to your project. Some Project Risk stems from the nature of what you are doing; there are certain risks common to any project (e.g. the unfamiliarity to users of the technology you are deploying). However, most project risk is under your direct influence; for example the skills of the project team, the level of governance effectiveness and so on. Stage Risk Finally, there is stage risk which is the risk associated with the particular activity of any given phase of the project plan. The Risk Log & Risk Plan In order to stay in control of the risks to your portal project, it makes sense to have a formal log of all risks, to which anyone involved with the project is entitled to add. You might use a formal workshop to first populate the log. Assessing Risks Each risk (however derived) can be assessed using a simple methodology, whereby the probability of the risk being realised (likelihood) and the size of the impact on the project objectives (severity) can be measured. The simplest system (based on the PRINCE project management method) is to give a score of 1-3 for likelihood and severity (where 1 is low and 3 is high). From these scores, the importance of each risk can be measured as the product of likelihood and severity. Clearly, any risk of importance 9 demands immediate attention, followed by risks rated 6 and so on. Risk Counter-measures The importance of each risk should be regularly maintained, based on the extent to which the likelihood and severity of impact change over time. For each risk, one should enter a counter-measure in the risk plan. Where a risk can be eliminated, then this will be the counter-measure. Where it cannot be fully eliminated, then risk mitigation actions will be the most appropriate. Issues Log A Risk is something that is yet to happen, whilst an Issue is something that has already happened. It may well be convenient to use the Risk Log to also track any issues on the project. Issues will generally fall into one of the following categories: (R) - Request for a change (in the scope of the project); (O) - An item has been identified that is Off-Specification; (Q) - A Question has been raised that needs to be resolved; (S) - A Statement of Concern has been raised by someone; and (I) - Other issues.

To score issues, just ascribe an importance score (of between 1 and 9). Managing Risks and Issues Once you have put a Plan in place, then it is important to regularly monitor and report on the counter-measures that have been deployed and whether or not they have been successful in reducing the overall risk profile of the project. For templates and examples of risks and issues pertinent to intranet portal deployment projects, please check out my chapter on Managing Risks and Issues in the (free to access) Intranet Portal Guide. If you act, manage and report regularly on risks and issues, you will have substantially improved your chances of project success!

Managing Project Risks (Part 1): Dont Be Snared by These 6 Common Traps (#1 in the series Managing Project Risks) By Adele Sommers When your enterprise decides to undertake a new endeavor whether its designing a new training program, planning a new service, or revamping an existing product this endeavor is called a project. It involves people, funding, resources, schedules, requirements, testing, fine tuning, and deployment, plus a host of other activities. You may have seen this phenomenon by now: projects are risk magnets. Why is that? There appear to be several factors involved. Managing project risk is a process that seems to be poorly understood by business owners and project managers. As a result, projects frequently experience problems with understaffing, schedule overruns, cost overruns, and unmet requirements. This article (the first of a series) explains six common traps that, when not fully recognized, can lead to unpleasant surprises. Heres what Ive observed over many years as both a project leader and participant: 1. Each project differs in some way, shape, or form from the last one. If all your projects were exactly the same, you could simply use a cookie-cutter approach to crank em out without losing any sleep at night. Although projects may share some similarities, a new project could very easily introduce several new, unfamiliar elements that can completely throw off your sense of balance - often without your even realizing it until its too late. 2. Projects are often constrained by finite conditions. Initially, you might hear limitations such as, We only have $1,200 and three weeks to have you complete all 18 training modules for this project. (What? Youre thinking that based on the requirements youve heard so far, this project should take a year and a half and cost three hundred grand!) Speaking of constraints, its not unusual for project sponsors or clients to ask for 1) low cost and 2) fast completion and 3) high quality and 4) many features in the final project deliverables. Although its understandable to want the greatest value for the money, unless the project is blessed with an infinite schedule and an unlimited budget, tradeoffs become necessary. Usually its only possible to achieve two or three out of four of these goals on a typical project. The tradeoffs might constrain the number of features, limit the quality, or both. 3. People chronically underestimate their time and effort. Whether its because of a perceived social stigma or a cloudy crystal ball, people typically have a difficult time deriving realistic project estimates. Given the number of project unknowns, coming up with accurate predictions can be tricky. (Smart project managers know this and frequently add buffers derived from records of actual past experience, commonly known as fudge factors, to project bids.) To complicate matters, people often feel pressured to further reduce the truth that is, to minimize whatever their already low calculations tell them it should take when they put together a bid. Whenever management pushes people to underestimate this way perhaps for fear of losing the project the risks can easily overwhelm and even destroy the projects success. 4. Project requirements are typically fuzzy at the beginning. Whether youre talking to a client, your boss, your colleagues, or your clients to figure out what the project should produce, whatever they say initially may sound as clear as a bell in some areas but very sketchy in others. Getting clarification on the fuzzy parts might entail many conversations with many people, and much more time than anybody ever imagined. 5. Requirements invariably shift over time. The minute after youve cemented the requirements with everyones agreement, scope creep begins. This means that the project needs may expand, shrink, or morph into something altogether different! These situations arise because the very act of creating something new can produce a result (or a series of results) that may exceed or differ from what people were capable of imagining at the start. And even when the team guards against it, pressure to include add-ons can stretch the scope beyond its limits.

6. Nearly everything else about the project is dynamic! Aside from the requirements changing, many other things can stop, start, or fluctuate during the project. Experienced people may leave and new people may come on board. Budgets could get chopped. Schedules might get slashed or sometimes even worse delayed. Resources may evaporate or not materialize in the right forms. Politics can sneak in and remove support, or require skipping critical steps such as testing. The list goes on and on. Studies of failed projects have revealed how difficult it can be to detect all of the red flags in advance. Unbridled optimism can block everyones ability to see clearly. Yet turning down an iffy project may be better than letting egos rule. What to do? As weve seen, projects can involve several highly dynamic variables. They often operate under tight budgets and schedules. People tend to miscalculate time, effort, and resources. Requirements frequently expand, shrink, or change. And shifting circumstances can pull the rug out from under everyones plans. Add these together and many projects will cook up a recipe for failure. But it doesnt have to be that way. You and your team can learn to avoid project pitfalls by paying close attention to the cause-and-effect relationships among these six important keys!

Managing Project Risks (Part 2): 10 Major Mistakes Your Team Can Avoid (#2 in the series Managing Project Risks) By Adele Sommers Does your organization see every opportunity as a must-win project, even when its a poor fit for your in-house talents? If so, this is one of several viewpoints that can blind your company to potential problems ahead. In Part 1 of this series, we explored how to recognize six common project traps. Now in Part 2, well review 10 major mistakes to avoid (or risks to flag) when choosing, estimating, and staffing your projects. First, its important to recognize that your organizational culture sets the tone for how you approach projects. For example, does your company always expect people to do more for less? Does the management routinely insist on or agree to unworkable schedules? Are team members encouraged to underestimate their realistic efforts? If so, these are signs that your organization may have a must-win-at-all-costs view of projects. You may want to consider how idealistic but impractical expectations could set the stage for project failure. In any case, if your business faces challenges with project budgets, schedule, quality, or features, try asking these 10 questions the next time youre considering a project: 1. Is the project non-compelling or a bad fit for the project team? A bad fit means that it doesnt fall within the general professional or technical arenas in which your company has accomplishments or your colleagues have expertise. Note that if your projects normally entail working with subject matter experts who would supply the information you need, this is not as great of a concern. 2. Will the project scope entail operating in unfamiliar territory? Even if its a reasonable fit, if a project involves requirements your team has never worked with before, you could be overly optimistic in assuming everyone can come up to speed quickly enough to be successful on the project. You may need to seek outside expertise, although this can introduce its own risks (see #6-7 below). 3. Are project requirements, such as product features, complex? A project that requires many complicated features to interact correctly vastly increases the potential for problems. One risk strategy could involve agreeing to phase in and test the complexity over time. Another could be to negotiate a reduction in the number or difficulty of the features to be completed. 4. Are the requirements pitted against an aggressive schedule? Time limits of some sort exist on almost every project, and drive nearly every other project expectation. Will there be enough time to implement the requested features at the desired quality level? If not, you may want to negotiate a longer schedule, agree to reduce the requirements, or phase in some features later. You could bring in more people, although this will involve more coordination.

5. Are too few personnel and resources available for the project? Project managers routinely lose sleep at night over what would happen if key project members were to leave. Or if the funding or resources were to get chopped or significantly delayed. Its one thing to have snafus occur later in the effort, but its another to start off unrealistically. So try not to underestimate your needs. 6. Will coordination with many different collaborators be needed? Involving many people means complex hand-offs. If your project will include client or third party collaborators, how will people interact? Should all parties remain in direct communication? Or should each group have a single point of contact? Also think about the division of work, and each groups responsibilities to the others. 7. Are the primary collaborators unfamiliar to the project team? If it does become necessary to recruit one or more new contributors, will you be able to verify whether they can do the job? If the unfamiliar parties have stretched the truth about their capabilities, you may be in for trouble. If theres a way to have them prove themselves first, thats ideal - or else have a contingency plan. 8. Are project team members discouraged from raising concerns? Before and after the project starts, team members will identify all kinds of challenges. Do you want people to raise red flags when they see potential problems, or do you prefer everyone to keep quiet, maintain a stiff upper lip, and work 24/7 if needed? The team culture will determine whether the members verbalize and address in a timely fashion the many pitfalls that can appear along the way. 9. Are there insufficient review and test cycles in the schedule? Allocating enough time for review and testing iterations commonly presents a challenge. Regardless of your initial planning, if project delays begin to add up, what will people want to cut? Can you afford to reduce testing and still deliver quality? 10. Are there no standard protocols for managing scope changes? When the inevitable add-on requests materialize, consider how theyll affect the project. Unless you have a tool, such as a project change request, to adjust the official budget and time frame, youll always be at risk for cost and schedule overruns. If you answered yes to one or more of these questions, it means that each is an area of risk that youll need to manage to ensure project success. Either create a workable plan for managing these risks, or consider whether pursuing the project is in the best interests of your organization.

Managing Project Risks (Part 3): How to Quickly Assess Potential Pitfalls (#3 in the series Managing Project Risks) By Adele Sommers Being optimistic is a wonderful thing, but being overly optimistic in the face of unrealistic odds can sabotage a projects success. Over-optimism abounds when people view every project as a must-win effort while failing to flag potential problems. In Part 2 of this series, we identified 10 types of risks related to choosing, estimating, and staffing your projects. After identifying the potential risks, the next phase entails assessing to what extent the risks can negatively affect your project in areas such as cost, schedule, quality, or features. This article (Part 3 of the series) explains how you can quickly evaluate any risks youve identified to see whether theyre likely to overwhelm your project. Risks You May Have Flagged Using the ideas in Part 2 of this article series, you and your team may have identified one or more concerns related to a project youre weighing. Ten considerations appear below; you might think of many others. If your answer to any question is yes or even maybe in relation to your project, it means that youve flagged a risk: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Is the project non-compelling or a bad fit for the project team? Will the project scope entail operating in unfamiliar territory? Are project requirements, such as product features, complex? Are the requirements pitted against an aggressive schedule? Are too few personnel and resources available for the project? Will coordination with many different collaborators be needed? Are the primary collaborators unfamiliar to the project team? Are project team members discouraged from raising concerns? Are there insufficient review and test cycles in the schedule? Are there no standard protocols for managing scope changes?

Assessing the Risks Youve Identified How Worrisome Are They? Once you have a list of risks, you can next assess them to find out whether they will be mildly annoying or could wreak havoc on your project. This is a quick and simple process for evaluating them: 1a. Start by giving each risk a name or label. Example: Imagine that your family has approached you about redecorating your kitchen because your relatives are coming for a family reunion the week after next. Your family believes that several changes are needed, as follows: Project requirements: 1. 2. 3. 4. New faux paint treatment on the walls Resurfacing all of the kitchen cabinetry Laying new tile on top of the vinyl flooring Installing crown molding around the ceiling

Time available: Two weekends (four days) within the next 10-day period. But you dont believe thats nearly enough time to complete the job! So, of all of the risks youve identified, you might label one of them Too Many Features/Too Little Time. This means that the project requirements are too numerous, too complex, or both, given the time available. 1b. Next, describe the kinds of problems this risk could cause. Also ask how likely it is to occur. For instance, if youre concerned that you wont have enough time in the schedule to incorporate everything requested, what problems might it cause whoever will be using the product, system, or solution? Are those chances fairly high? Describing these concerns can help everyone on your team agree on just how serious that potential risk is. Example: Your relatives might arrive while the work is still in progress, and the kitchen will be unusable. Also, if you bow to the pressure to hurry, the quality of the work may be low. Both of these problems are likely if your family members try doing the work themselves, since theyre not skilled in home improvements.

2. Give each identified risk a potential impact score or rating. You can give each risk a High Impact, Medium Impact, Low Impact, or No Impact score, based on simple numbers you can derive easily. One way is to assign relative values to the negative impact a risk may have on the project cost, schedule, quality, and features with a different value possible for each of these four areas. For example, a high negative impact might be a 9, a medium impact a 5, a low impact a 1, and no impact a zero. Example: Your kitchen redecorating project might earn scores like those below.

Cost - You estimate that by doing the work yourselves, youll possibly save money (if you dont botch the job). So your Too Many Features/Too Little Time risk might have a medium negative impact on cost, for a score of 5. Schedule - Since you feel backed into an almost unworkable time frame, you expect a high negative impact on schedule, for a score of 9. Quality - Because you expect to rush through the project, you anticipate a high negative impact on quality, for a score of 9. Features - Some features probably cant be completed, regardless of how fast you go. You foresee a high negative impact on features, for a score of 9.

The total score for all four areas in this example is 32, very close to the maximum. When you complete the process for any other risks you identified, you can compare this score with the others to see which risks are of greatest concern. You can then determine the priority order in which to mitigate them. When you are finished with this phase, youll have a set of named and assessed risks. Following this, Part 4 in the series will explain how to brainstorm ways to avoid, eliminate, work around, or otherwise mitigate each risk.

Managing Risks of Fixed Schedules By Ray W. Frohnhoefer As Project Managers, we often have to perform with a fixed schedule. This type of situation can occur for almost any project or industry, but it is a special issue in the software industry when we want to meet monthly, quarterly, or other periodic release schedules. Here are my top 5 tips for successfully managing the risk and meeting the deadline: 1. 2. 3. Be sure there is a project charter for each release, with the high level time, resources, budget, and deliverables scoped out. Factor in time off for vacation early since this can have a big impact if it comes as a surprise later. Any surprises warrant an immediate review. Regularly review delivery metrics. Use experience to improve estimating and the ability to meet targets. Build an incentive/recognition plan around achieving superior metrics (not just meeting the target). Count on product and project management being between 5% and 20% of your schedule this rule of thumb will help make sure you dont stretch the PMs too far. 5% for just scheduling and coordination, 20% for scheduling, coordination, requirements, and documentation. This makes sure there is a consistent level of management. Complete all your highest effort deliverables early in the cycle. Dont make the end date too aggressive or the team too lean. Better to get the team working on the next cycle or drop in a few low effort items toward the end to fill the time if necessary better to finish early than blow the date.

4. 5.

These are the things the project sponsor, Project Manager, and functional manager can do to assure a fixed schedule is nailed!

Managing Risks of Fixed Costs By Ray W. Frohnhoefer Previously we looked at fixed schedule, so its only natural to want to look at fixed costs too. Or perhaps I should more precisely say fixed price since fixed costs have a connotation of overhead. And theres a further clarification to make as well (finances are so much more complex than schedule and time) were talking about risk to the seller. Many buyers like fixed prices since they know exactly what their budget will be, but its the seller who has to manage most, if not all, of the risk. Now with the clarifications aside, heres my top 5 list: 1. 2. Well defined scope and specifications: Having a well defined project scope and necessary specifications will make it easier to manage and estimate. Uncertainty leads to errors. Diligently completed estimates: if there was ever a time to be cautious in estimating, this is it. Obviously youre not going to be able to sandbag, but a carefully thought out and documented estimate provides a solid basis for success. Be sure to have it carefully reviewed and drill down where ever there is uncertainty or poorly defined specifications. Heres a great place to look at historical information on similar projects. Track all expenditures as they happen, not when the invoice arrives: problems like delayed mail or slow vendor billing cycles can allow problems to go unseen. Estimate every expenditure and then compare to actuals. Use earned value methods if possible. Any deviations or unresolved differences need an immediate review. Track time as carefully as costs: time often translates to money, and lost time can translate to unexpected costs. Dont be afraid to negotiate: its called fixed price, but the unexpected still happens. Obviously things like I forget to add it into the estimate arent going to fly, but legitimate additional time, expenses or scope can be negotiated if the costs become excessive. My company was the buyer of a fixed price contract that went on for an additional year or so because the company had an internal change of plans and was unable to assist the seller with certain aspects of the project originally promised. The seller was patient for a long time, but finally came back and rightfully negotiated to have some of the additional costs covered.

3.

4. 5.

Lessons Learned Report By The Office of Government Commerce - OGC, UK

Purpose: The purpose of the Lessons Learned Report is to bring together any lessons learned during the project that can be usefully applied to other projects. At the close of the project it is completed and prepared for dissemination. As a minimum, lessons learned should be captured at the end of each stage of the project; ideally a note should be made of any good or bad point that arises in the use of the management and specialist products and tools at the time. Fitness for purpose checklist:

Has every management control has been examined? Have all the reasons for all the tolerance deviations and corrective actions been recorded? Is input to the lessons learned log being done (as a minimum) at the end of each stage? Is there an analysis of the success of quality reviews and other types of test used?

Suggested contents The Lessons Learned Report should contain:

Which management and quality processes: went well went badly were lacking. A description of any abnormal events causing deviations from plans. An assessment of technical methods and tools used. Recommendations for future enhancement or modification of the project management method. Useful measurements on how much effort was required to create the various products. Notes on effective and ineffective quality reviews and other tests, including reasons why they worked well or badly.

Source information:

Notes:

Observation and experience of the processes Completed work packages Comparisons of stage plans with what actually happened

The Lessons Learned Report should be viewed as information that can be shared (although sometimes areas may have to be kept confidential) as well as what would be valuable for future projects to the form of recommendations on any enhancements or modifications. At the start of a new project, previous Lessons Learned Reports should be reviewed to consider how lessons learnt from previous projects could be applied to the project. The data in the report should be used by a corporate group, such as quality assurance, who are responsible for the quality management system, in order to refine, change and improve the standards. Measures of how much effort was needed for products can help improve future estimating.

Planning Before A Customer Interview Is Completed - Project Management Mistake #1 (#1 in the series 15 Deadly Project Management Mistakes Government Agencies Make Which Cost Them Revenue, Time & Efficiency) By Keith Mathis - PM Expert Live Project Management in a government setting is here to stay. It is one of those skills which help deliver the greatest value to the most individuals. During a time when all agencies are faced with tight budgets and limited staff, we must make sure we can complete projects in the shortest and most economic way. This series focuses on some of the most common blunders made by agencies when working on projects. Many of these mistakes are not a one-time event, but are part of the culture of the organization and happens in 90% of the projects. Due to enormous pressure, project teams are faced with beginning activity on a project prior to completing a detailed project plan. This causes a great deal of hardship and mistakes which cost time and money for the organization as well as frustration to the project team. Reasons why planning takes place before the interview There are three basic reasons why planning takes place prior to a detailed interview of the customer and/or the project sponsor. The first reason planning takes place before a thorough interview has been conducted is based on the fact that, in the American culture, we have substituted activity for planning. This means we want activities to be happening at a record pace to demonstrate that we are running the project, even though there is no plan in place. Unless project managers and project sponsors come to the understanding that interviewing the customer and setting precise objectives must be completed up front, we will continue to have blurry plans and numerous amounts of rework on our project. The second reason why planning takes place prior to an interview is that no one has taken the time to understand the real goal and objective of the project. This means the project team is faced with having to plan the project on the run with limited understanding of the real goal. Planning a project while on the run is not an effective way of using manpower and resources for the project. In most cases, it will cause the project to take longer, cost more, and experience numerous gaps. The third reason why project plans are created without an interview is the project sponsors and project managers do not see the benefit of getting all the information upfront. Some project managers have been trained in a culture that disperses information in small, bite size pieces rather than in large chunks. This means that the average project is being planned with only knowledge of the few short goals rather than a full understanding of what the project should look like at completion. Need for interview Interviewing the customer is the best way to gain a thorough understanding of the projects objectives and goals. Unless a project sponsor or project manager has this knowledge, the project will take longer and cost more than anticipated, and, in many cases, will require a great deal of rework. All of these reasons emphasize the need to take the time upfront to interview the customer and make sure you understand their goal, objectives, and timeframe. Managing Project Risks (Part 2): 10 Major Mistakes Your Team Can Avoid (#2 in the series Managing Project Risks) By Adele Sommers Does your organization see every opportunity as a must-win project, even when its a poor fit for your in-house talents? If so, this is one of several viewpoints that can blind your company to potential problems ahead. In Part 1 of this series, we explored how to recognize six common project traps. Now in Part 2, well review 10 major mistakes to avoid (or risks to flag) when choosing, estimating, and staffing your projects. First, its important to recognize that your organizational culture sets the tone for how you approach projects. For example, does your company always expect people to do more for less? Does the management routinely insist on or agree to unworkable schedules? Are team members encouraged to underestimate their realistic efforts? If so, these are signs that your organization may have a must-win-at-all-costs view of projects. You may want to consider how idealistic but impractical expectations could set the stage for project failure. In any case, if your business faces challenges with project budgets, schedule, quality, or features, try asking these 10 questions the next time youre considering a project: 1. Is the project non-compelling or a bad fit for the project team?

A bad fit means that it doesnt fall within the general professional or technical arenas in which your company has accomplishments or your colleagues have expertise. Note that if your projects normally entail working with subject matter experts who would supply the information you need, this is not as great of a concern. 2. Will the project scope entail operating in unfamiliar territory? Even if its a reasonable fit, if a project involves requirements your team has never worked with before, you could be overly optimistic in assuming everyone can come up to speed quickly enough to be successful on the project. You may need to seek outside expertise, although this can introduce its own risks (see #6-7 below). 3. Are project requirements, such as product features, complex? A project that requires many complicated features to interact correctly vastly increases the potential for problems. One risk strategy could involve agreeing to phase in and test the complexity over time. Another could be to negotiate a reduction in the number or difficulty of the features to be completed. 4. Are the requirements pitted against an aggressive schedule? Time limits of some sort exist on almost every project, and drive nearly every other project expectation. Will there be enough time to implement the requested features at the desired quality level? If not, you may want to negotiate a longer schedule, agree to reduce the requirements, or phase in some features later. You could bring in more people, although this will involve more coordination. 5. Are too few personnel and resources available for the project? Project managers routinely lose sleep at night over what would happen if key project members were to leave. Or if the funding or resources were to get chopped or significantly delayed. Its one thing to have snafus occur later in the effort, but its another to start off unrealistically. So try not to underestimate your needs. 6. Will coordination with many different collaborators be needed? Involving many people means complex hand-offs. If your project will include client or third party collaborators, how will people interact? Should all parties remain in direct communication? Or should each group have a single point of contact? Also think about the division of work, and each groups responsibilities to the others. 7. Are the primary collaborators unfamiliar to the project team? If it does become necessary to recruit one or more new contributors, will you be able to verify whether they can do the job? If the unfamiliar parties have stretched the truth about their capabilities, you may be in for trouble. If theres a way to have them prove themselves first, thats ideal - or else have a contingency plan. 8. Are project team members discouraged from raising concerns? Before and after the project starts, team members will identify all kinds of challenges. Do you want people to raise red flags when they see potential problems, or do you prefer everyone to keep quiet, maintain a stiff upper lip, and work 24/7 if needed? The team culture will determine whether the members verbalize and address in a timely fashion the many pitfalls that can appear along the way. 9. Are there insufficient review and test cycles in the schedule? Allocating enough time for review and testing iterations commonly presents a challenge. Regardless of your initial planning, if project delays begin to add up, what will people want to cut? Can you afford to reduce testing and still deliver quality? 10. Are there no standard protocols for managing scope changes? When the inevitable add-on requests materialize, consider how theyll affect the project. Unless you have a tool, such as a project change request, to adjust the official budget and time frame, youll always be at risk for cost and schedule overruns.

If you answered yes to one or more of these questions, it means that each is an area of risk that youll need to manage to ensure project success. Either create a workable plan for managing these risks, or consider whether pursuing the project is in the best interests of your organization.

Top-down Planning With Little Input From Those Working On The Project - Project Management Mistake # 2 (#2 in the series 15 Deadly Project Management Mistakes Government Agencies Make Which Cost Them Revenue, Time & Efficiency) By Keith Mathis - PM Expert Live Project Management in a government setting is here to stay. It is one of those skills which help deliver the greatest value to the most individuals. During a time when all agencies are faced with tight budgets and limited staff, we must make sure we can complete projects in the shortest and most economic way. This series focuses on some of the most common blunders made by agencies when working on projects. Many of these mistakes are not a one-time event, but are part of the culture of the organization and happens in 90% of the projects. Due to enormous pressure, project teams are faced with beginning activity on a project prior to completing a detailed project plan. This causes a great deal of hardship and mistakes which cost time and money for the organization as well as frustration to the project team. The responsibility for planning the project is always a hot topic of debate in any of our seminars. There seems to be a consensus that individuals are planning the project, setting deadlines, and establishing budgets with little or no input from the frontline worker. In a government setting it is very common to hear this verbalized by the line worker. Many forget that upper management is normally the individuals who have control and understanding of the resources as well as the organizations larger mission. There are three main areas which should be considered when having top-down planning of a project. Each of these considerations must be looked at based on the individuals and their expertise in breaking down the project. There is a great deal of strength using both upper management as well as the line employee in putting together a plan, budget, and time sequence of any project. Top-down planning is old style Top-down planning is a demonstration of the old style of management, which was used consistently in the nineteen fifties through the eighties. Top-down planning makes the assumption that upper management has the best processes and ideas to run a project smoothly. In many cases, this is true when management has a great deal of experience with some of the specialized projects of the government agencies. However, top-down planning can hurt a project and, in many cases, destine it for severe problems because the employees have not had an opportunity to give input. Top-down planning could reinforce the Peter Principle During the nineteen seventies, management was introduced to a new phrase which was called the Peter Principle. This principle meant that individuals are promoted until they reach their level of incompetence, at which time the promotions cease. To put it a different way, people are promoted until they start doing a bad job, and then they are left in that position until retirement or until they quit. What if this principle is being applied to the project planning process in your agency? What if the person doing the planning has been promoted to their level of incompetence? If they are producing project plans and they happen to be at their level of incompetence, they are producing plans which are substandard to front line employees who have an expertise in the project. This does not mean that every manager is demonstrating the Peter Principle. Most managers have worked extremely hard to move up in the organization, and they are making the best decisions to run the organization toward the fulfillment of its mission and objectives. However, it is not uncommon to run across individuals who are a walking example of the Peter Principle, and they are hurting their agency because they have position power. Top-down planning limits buy-in from the team Is team buy-in important to your project success? Do you desire for your team to generate ideas and solve problems on their own? If the answer to these two questions is yes, then top-down planning might be something which limits buy-in and input from your team. When an organization experiences a great deal of top-down planning from their executive staff, a culture is created that signifies a lack of trust toward frontline employees. The frontline employee begins to stop making even the most common decisions in a project and begins running all solutions through the management team. This kind of response slows down the project and prevents the project team from taking the needed responsibility.

In conclusion, one of the best things a project sponsor or manager can do in project planning is to set the parameters and then work with the team to come up with the needed timeline and expectations. This will reinforce input and buy-in from the team while assisting upper management and controlling the outcomes.

Creating Teams With Improper Skills - Project Management Mistake # 3 (#3 in the series 15 Deadly Project Management Mistakes Government Agencies Make Which Cost Them Revenue, Time & Efficiency) By Keith Mathis - PM Expert Live Have you ever been on a project team which was ineffective or did not possess the proper skills for running the project in a timely fashion? This can be very frustrating to the project team as well as the customer and can damage the progress and confidence in project planning. How does something like this happen? What do we do when we have project teams with improper skills? All of these questions are very important and must be examined in order to make the project advance in an effective manner. Reasons for teams with improper skills There can be several reasons why a project team does not have the skills needed to complete a project. In most cases, a project team will possess 80% of the skills and will need to bridge the gap for the remaining 20%. This gap can be bridged with the usage of other experienced team members, outside contractors, or internal training to provide skills to the project team. The first reason why teams have improper skills is the project requirements have changed but the team has stayed the same. Some projects evolve and change objectives while being completed. This requires changes of skills and core competencies within the project team in order to handle this type of evolution. The second reason why teams have improper skills is due to a lack of project management training. Many project teams have basic skills for running a project, but over time they become lazy and allow those skills to become cold or dormant. This means that they must be reminded in team meetings and with updated training. The third reason why teams have improper skills is because the team has never possessed the skill in the first place. They try to use knowledge others possess. Some project teams are doing the best they can with a calendar and excel sheets. They have never been taught a proper way of running a project so they revert back to the skills that they know. This makes it very difficult for a project team to monitor one another because there are numerous systems being used to track and calculate project success. It is very important for project teams to keep their skill levels strong and effective. This can be done very easily through the usage of training in short intervals at the end of project meetings. In many cases, the training will need to only be 15 to 30 minutes in length to keep the skills fresh and to build new techniques into your project. Our clients have enjoyed our free monthly e-zine which reinforces these skills. Each month a different skill is the focus. Roles And Responsibilities Are Not Spelled Out - Project Management Mistake # 4 (#4 in the series 15 Deadly Project Management Mistakes Government Agencies Make Which Cost Them Revenue, Time & Efficiency) By Keith Mathis - PM Expert Live Many projects are hurt because the team members are unaware of their roles and responsibilities. This comes about due to a number of reasons. Foolishly, project managers and sponsors think that their team should already know which role they are fulfilling. When roles and responsibilities are not explained, we are leaving this understanding up to the individual team member. When this happens, they are going to miss the mark and function in a role which is not consistent with a project managers outcome. When they do not perform as desired, there is frustration and anxiety. Lets examine the most common reasons roles and responsibilities are not fulfilled. Misunderstanding of role Project team members work on a number of project teams. On some of the teams they are expected to be more influential in the manner of interaction, while on other teams they are expected to function in a supportive nature. Making sure the roles and responsibilities are discussed in the early stages of a team meeting will reduce these frustrations and cause the team member to engage in a manner which is desirable.

Being placed in a role which is out of ones expertise Team members are expected to walk on water, if needed. This causes many of them to take on jobs within the project team which are out of their comfort zone and expertise. What you will notice is many of the team members are wonderful people, and they will try anything the project sponsor or manager desires. However, if we really want success in these new roles, one should make sure you are providing education to expand their skill set and then put these new skills into practice. Explaining where they can get information and help Working on a team requires accountability. Project managers are assuming the individuals know where to get the needed help and assistance. They think that if they do not know, they should just ask. For some team members, they are assertive and confident enough to do this when needed. But what about the non-assertive team member? What about the quiet team member? There are times when a team member is not sure what to do and where to get help when problems arise. Project managers can reduce a great deal of stress and encourage their team in a powerful way if they will give direction on where they can get questions answered and help on their assignments. In closing, if you desire for your team to take on more in the project, take steps to equip them with the correct skills and provide them support on how to solve their problems.

Little Accountability When Productivity Is Low - Project Management Mistake # 5 (#5 in the series 15 Deadly Project Management Mistakes Government Agencies Make Which Cost Them Revenue, Time & Efficiency) By Keith Mathis - PM Expert Live Running project teams can become very difficult, especially when you are not their immediate supervisor and do not have position power over them. This is complicated when project teams have no formal way of evaluating the work their team members have completed or a way to give feedback to the team members supervisor. This results in team members who are working on projects and have a very low productivity level, but they continue to get great performance evaluations from a supervisor. We are going to look at the reasons this happens, ways to change accountability in your culture, and, finally, how to set up feedback sessions for tracking project teams and holding them more accountable. Reasons for low accountability There are three primary reasons why project teams struggle with little or no accountability. Many of these can be removed through simple communication, the setting of standards, and detailing the roles and responsibilities of each team member. Lets examine each of the three reasons for little accountability on a project team. The first reason why there is a lack of accountability in projects is due to the usage of staff from various departments who report to difference supervisors. This has become more complicated due to the internal culture of most agencies which requires the only person to hold a worker accountable would be their direct supervisor. Problems surface when communication breaks down and there is a lack of feedback about the workers performance on a particular project. Poor employees know about this gap, and they have started using this lack of communication to their advantage. The second reason why there is little accountability on many project teams is due to a lack of proper evaluation of the work one has performed. As project teams develop, there should be a reasonable amount of evaluation taking place to maintain quality, communication, and make sure the objectives of the project are being achieved. When there is no internal evaluation to maintain quality, it compels the team to put off examining quality until the end of the project. This forces corrective actions to take place at the end of the project which increases budget and time. Unless evaluation is examined throughout a project and individual roles and responsibilities of each team member are detailed, hold the entire team accountable even though it might only be one or two team members. The third reason why there is little accountability is due to an improper manner of setting up the project team. Project teams are set up without a code of conduct or a value statement of how the team plans to work and will conduct themselves. Without this code, many teams find themselves floundering as they try to hold each other accountable with no position power. Since there is no standard that the project team is agreeing to follow, each individual is a standard among themselves with different measuring indicators. Unless the code or standard is set up in the beginning, this team will continue to have conflict after conflict throughout the entire project. Changing accountability culture

Changing accountability culture must take place with the support of the project manager, project sponsor, and the entire project team. Unless you have the support of the project manager and sponsor, the team will notice a lack of resource leverage. Changing the culture of the project team to one which possesses more accountability happens through a series of detailed steps rather than just one activity. The culture of an agency can be defined as the way we run the organization and what is allowed. This can be demonstrated by how we treat individuals, what is talked about, what is joked about, as well as what has been said behind the backs of others. All of these examples demonstrate culture. When we focus on a culture which violates accountability, we are discussing a problem which sabotages positive work and reinforces the slug mentality. The following is a listing of some of the events which must take place in order to change the accountability culture in your project team and in your agency. First, the organization must detail what the new culture design or model will be. This means having a good idea of what would bring about the best successful situation for the agency. It can be something as simple as shifting from a strong autocratic style to one which is more team oriented. In other situations it is making adjustments on how communication is distributed among the personnel. Regardless of what is needed, there must be a picture in the leaderships mind as to the proper culture for the future. Second, you must brainstorm which personnel will be the most supportive of this new culture and get them active in making the shift. Some personnel struggle with any type of change taking place in an organization. There are other employees who love the thought of change, especially when shifting culture is described. What you want to do is get employees who are supportive, as well as those who might be resistant, working on making the needed changes. Resisters will bring up ideas of future hurdles that might hinder the shifting of culture. As you solve these problems within the team and prior to rolling it out to the entire agency, you have actually made the changing of your culture a stronger plan than before. Third, you must be willing to weather the storm of negativity that follows the shifting of a paradigm such as this. People have the tendency to be more negative than positive, especially during times of massive change such as the one being discussed. You will need individuals who will verbally support the change of this culture in spite of a high level of negativity from others. Setting feedback sessions for tracking Creating the feedback sessions is one of the best ways for monitoring the performance of the project team. These feedback sessions must include detailed evaluation of the quality, communications, roles and responsibilities, budget, and cohesiveness of the project team. To have a feedback session and refuse to be involved in evaluating these details is like leading a team to shoot at a target blindfolded. Feedback sessions can be done on a weekly, monthly or quarterly basis. They are not done just to examine the negative things wrong with project. They are done with a motive of evaluating performance and progress. This means in a normal feedback session, it is possible not only to discuss where a team has not measured up but also to point out those areas where outstanding work has been accomplished. In summary, it is very important for the culture of any project to hold team members accountable. If this is not taking place, then it is the responsibility of the project manager, project sponsor, and each team member to discuss the situation and fix it immediately.

Timeline Is Not Realistic - Project Management Mistake # 6 (#6 in the series 15 Deadly Project Management Mistakes Government Agencies Make Which Cost Them Revenue, Time & Efficiency) By Keith Mathis - PM Expert Live Creating a timeline for a project can be a battleground between the project team and the project sponsor. Each agency has its own policy as to who will calculate the timeline for the project. Sometimes timelines are calculated by the project sponsor, other times it is calculated by the project manager, and in many cases, there is a great deal of input from the project team. There are strengths and weaknesses regardless of which manner an agency chooses to use in figuring time. However, there are three primary concerns which should be considered regardless of who calculates the timeline in a project. When these three areas are violated, it causes the timeline to be incorrect and not realistic for the project team. This may result in shoddy work, or, even worse, the timeline may not be taken seriously. Planned by someone on best guess scenario

When a project is started, there are many circumstances in which timing is a guesstimate without the benefits of real life calculation. This is not that uncommon in the early stages of project development discussions. However, as a project continues to develop and evolve, the timeline should move farther away from a guess and more to a calculated destination. The areas where this impacts the agency most is where the best guess method gets locked in as if it were a legitimate, calculated timeline. Due to embarrassment or lack of time, no one discusses this mistake and so the project plan has major errors. This error impacts performance, morale of the team, and expectations of the customer. Unless these areas are changed, we are reproducing an incompetent project process in the initiation phase of every project. Planned short times to force team to work harder Another incident which is very frustrating to project teams is the determination to shorten the timeline on purpose to force more work out of the project team. An example of this would be when a timeline has been calculated and a project sponsor changes the calculation, reducing its time by 10 to 30 percent to make sure all contingency time has been cut out of the project. The cutting of this time is due in part to demonstrate ones position in power over the process. Does this mean that a project sponsor should never change the timeline? Of course not. There are times when we have noticed a project plan which has been calculated with an extreme amount of contingency time. During those incidents, the project sponsor bears the responsibility of discussing those findings with the project manager and possibly even the team, and the result will be to shorten the plan. This means we must be fair to our project team when calculating time if we expect them to work hard in meeting all desired deadlines and core objectives. In closing, the best way for an agency to calculate time is to establish the basic time calculation model that can be used extensively by all project sponsors, project managers, and project teams. Establishing a model for calculating time is one of the most fundamental elements of training that can benefit an agency as well as reduce stress and conflict between the project team and sponsor. Work Breakdown Structure Was Shallow - Project Management Mistake # 7 (#7 in the series 15 Deadly Project Management Mistakes Government Agencies Make Which Cost Them Revenue, Time & Efficiency) By Keith Mathis - PM Expert Live Any successful project must have a detailed work breakdown structure (WBS). We can define a WBS as the breaking down of a project into smaller pieces for the purpose of tracking budget, time, and responsibility. Many projects struggle due to the WBS being created in a very shallow and superficial way. What this means is that the project has not been broken down into small enough units of time, budget, or structure to be able to accomplish the goals. Limited breakdown Some projects are broken down with a limited amount of structure. This means that an individual or team has broken down the project, but they have not gone deep enough into setting up the design and plan for accomplishing its objectives. It is not uncommon to see this demonstrated when you have inexperienced individuals. Some cases show this as an evidence of a team under a great deal of pressure to produce a plan, but they have violated the foundation of core competencies of standardized project management. Limited breakdown of the project leaves a great deal of gaps open for interpretation by the project team. These gaps can create work stoppage or more time delays due to lack of planning in moving the project forward. It is best for a project to have a detailed breakdown with all the individual activities and tasks documented to assist in tracking those units of time and budget. Refusal to plan the project with enough detail Limitations in planning a WBS is normally demonstrated when a project planning sheet only goes two or three levels in depth of the plan. If the main components of the project are broken down followed with only one or two levels, then it is possible the project is going to be hit with unforeseen time delays as well as budget over extensions. Normally, in a project plan you will have the main components of a project followed by major tasks or activities, followed by minor tasks or activities, and then, finally, subtasks bring up the remainder of the project. You will notice an example of the breakdown in the following diagram.

Project A. Major Task 1. Minor task a. Sub task 1. Sub-sub task

This diagram points out at least four levels to a project plan in dissecting its breakdown. Unless a project manager or its team can breakdown a project into multiple levels, they will constantly be finding gaps in the timeline as well as budget. Assumptions are forgotten or limited in focus Every project has a certain level of assumptions built into the planning process. These assumptions are connected to the way past projects have been planned or have been run. Assumptions can best be defined as those foundational views considered taking place if you are going to complete a project successfully. For example, it is assumed that if a customer wants a project, they are going to meet budgetary requirements and give input into the goals or core objectives they desire the project to achieve. Unless the customer is willing to do this, there is no way that a project can be achieved. This is a simple example of our assumption. There are also assumptions such as human resource allotment, budgetary allotment, time, tools and equipment provided, as well as communication and feedback in order for a project to move forward. In conclusion, it is necessary to have all of these components working together in order to create a WBS that is effective, correct, and timely. Unless a WBS is able to be broken down into small, measurable pieces and detailed with realistic assumptions, the project cannot be successful. Risk Analysis Was Limited In Depth - Project Management Mistake # 8 (#8 in the series 15 Deadly Project Management Mistakes Government Agencies Make Which Cost Them Revenue, Time & Efficiency) By Keith Mathis - PM Expert Live Project risk must be examined and planned for in order to prevent untimely delays. Project teams fail to discuss the risk of a project many times due to the thought that it is focusing on negativity. Conducting a risk analysis on a project is needed to help build a solid contingency plan to prevent the project from running across delays which could cost large chunks of time and money. The lack of a risk analysis seems to come about due to many projects never examining the performance, risk, or implementation of previous projects and compare those results this one. This means that the project team is not learning from past performance and has to make the same mistakes themselves. When discussing a risk analysis, one should be examining two issues. What can go wrong in the project? What is the impact if it does go wrong? The following will examine both of these issues. No discussion on what can go wrong Project planning should be filled with a detailed examination of what can go wrong in each phase of the project. This means engaging your team to think outside of the box and in terms of what has the highest possibility of malfunctioning. In many cases, individuals on your project team who are more negative in nature can assist in creating this list the fastest. Do not think this is just a time to be negative about the project. This is a time to spend looking at those areas that have the highest potential for failure, while building and planning time for preventative measures to keep that from happening. Unless a project team is willing to discuss these issues, they will constantly run from crisis to crisis or be exposed to planning on the run. Crisis plan was left out Crisis planning is very important once a project team has examined risk. This means that the project team has itemized each risk and has provided a detailed way of solving or reducing the risk from taking place. You will notice on many projects that there is a detailed crisis plan for those areas which have a severe amount of devastation if it goes wrong. An example of this would be the nuclear power plants that have thought through every possibility and have made provisions for either solving the crisis or reducing its effect. Some project teams feel that this is not necessary since their project is not as critical as previously discussed. Making this change is extremely hard in many cultures since project teams often plan on the run. To do this correctly the project team must spend time and effort thinking through each critical point of the project in determining the risk, its criticalness, and ways to reduce its effect.

Little Or No Implementation Plan - Project Management Mistake # 9 (#9 in the series 15 Deadly Project Management Mistakes Government Agencies Make Which Cost Them Revenue, Time & Efficiency) By Keith Mathis - PM Expert Live

Implementation of the project is very important in order to keep it current. Most participants verbalize they have a schedule created but have no implementation plan to drive each phase of the project. After a WBS has been created, it is important to spend time in designing an implementation plan. An implementation plan is defined as a plan created with dates and times for starting each section of the WBS. Implementation plans work best when you also have people designated to accomplish whatever work you have assigned. Objectives of implementation plan The implementation plan is used to make every section of the WBS function as easy as possible. It is created to make sure that all roles and responsibilities are clear to the individuals, as well as dates, times, and sequence for running the project. When an implementation plan is created correctly, it allows all team members to understand what is happening in the project and when they can expect their duties to begin. How and when to implement Implementation must be conducted in a very structured and calculated away. This means that the project team must be very realistic in designating who should do a particular portion of the project as well as when it should begun. In some cases, the project team will build in a certain level of contingency time in order to assist the project timeline. This means that a project team might examine the earliest time an activity can start, the latest time an activity can start, and calculate the median time for most dates. This method is used by many experienced project managers and their project teams. Its strength is that dates and times are being calculated with small amounts of contingency time built into the plan. Implementation failure happens due to six main reasons. Each of these reasons can be overcome if proper steps have been taken on the front end of the project to prevent them from coming about in the first place. Reason #1 Not making a decision until it is too late Project teams struggle with decisions throughout the project. However, some are plagued with an uphill battle in making the right decision. They are trying to consistently run a perfect project and make sure they never make a mistake. This is normally done because the project team is trying desperately not to be blamed for failure or the lack of progress in the project direction. Fear of making the decision will sometimes cause people to panic, and they are consistently trying to play it safe. Playing it safe will not always produce the best solution. Reason #2 Waiting too long for data Waiting too long for data is normally committed by cogitators on the team who desire solid information before making a decision. Correct information is a wonderful thing to assist in working on a project; however, there are some instances where that information is coming far too slow or is nonexistent. Refusal to make a decision is in itself a decision. Each project team needs to understand that their refusal could kill the project faster than making a decision on limited knowledge. With all the resources that we presently have in our culture and organization, we should have a good idea of what needs to be done even when data is sparse. Obviously, we would love to work on perfect projects with this great amount of correct data to make the right decision every time. Reason #3 Upper management goes in and redirects the plan We often hear of situations where upper management will violate a project plan with autocratic orders and go in a new direction. Many times this direction makes no sense to the project team and has been brought about with no communication indicating what has created this change. Our clients typically report this has been very common in the workplace. They indicate that communication is only in a top-down manner, and they are unable to give feedback to their boss in a receptive manner. During one training session, a participant indicated that some projects changed over and over again due to upper management making unscheduled and un-communicated changes to the plan. This in no way means that upper management does not need to make changes from time to time and to usurp authority over previous plans. However, this works best when the project team has been kept in the communication loop, and they understand what the real goal and motivation this change revolves around. Reason #4 Jumping from one priority and focus to another during the project Priority management is one of the hardest things to do when running multiple projects. It is not uncommon for individuals to jump from focus to focus and project to project based on the crisis at the moment. Sometimes, when examining the project, you can determine that the reason they are struggling is because there is a trend in putting this project second based on the crisis of the day. We tend to favor projects that have an immediate crisis and treat them as if they are the highest priority. The frustration with this is that projects which are lower on the priority list are sometimes treated with the same level of urgency as strategic projects. Running projects based on crisis confuses the project team and reduces the potential that other projects will be on time and budget.

Priority management of the project must be clear and concise. Each team member must remember which projects have the highest priority even though they have to deal with the crisis of the day. This means if priorities have really changed, the team must understand the new order projects are going to be running. Reason #5 Sabotage by internal fighting from individuals in the organization An additional reason for implementation failure is due to organizational sabotage and fighting. This happens when one department does not see the need to provide support for another departments project. An example of this is when one project is of highest priority for you but is a secondary priority for the people assisting you. When you become our client, we focus on this area and discuss ways to reduce internal fighting from individuals as well as break down the silo effect throughout your organization. Learning this skill naturally opens up communication and increases the potential success for your project. This process also builds higher morale throughout the agency. Reason #6 Failure to train the project team Training is a needed skill to make sure that the project team is running in a proper fashion. The type of training will differ depending on the skill level and expertise of team members. A good way to train your team is to make it part of your normal project team meetings. We have encouraged our clients to plan to update skills by conducting 15 to 30 minutes of training periodically in their team meetings. This can be as brief as handing out articles on a particular topic to as deep as a multi-slide presentation with handouts. Regardless of what you do, you want to consistently expand the skills and application of your project team. As you can see, each of these six reasons for implementation failure can happen to any project team regardless of how high functioning they have been in the past. A good implementation plan will reduce your failure rate and speed up your project time as much as 3% to 20%. The increase will depend on the priority of the project and how well the project team fulfills the desired plan. Regardless, each project should have a detailed implementation plan with a thorough examination of these areas that have caused others to fail.

No Communication Plan - Project Management Mistake # 10 (#10 in the series 15 Deadly Project Management Mistakes Government Agencies Make Which Cost Them Revenue, Time & Efficiency) By Keith Mathis - PM Expert Live Communication plans can benefit the project by detailing exactly how much interaction a project team will have with the various stakeholders of a project. We will examine how to create a communication plan as well as problem areas to where communication is lost or misunderstood on a project. Have you ever been working on a project and feel that you do not know what is happening? Have you ever attended project meetings only to leave more confused afterward than before you came? All of this revolves around communication. Communication within a project is one of the most important tools for making sure that people get clear directives and do what they are supposed to do. As part of a balanced approach to keeping the communication channels open, each project team should create a detailed communication plan. This plan can be defined as a pointed document clarifying how often communications and reports will be completed. Communication flow to each of these reports must be accomplished in a specified timeframe and revolve around giving particular data and updates. Communication plan defined A communication plan is defined as a document which spells out the process and the timing for communication in a project to all interested parties. This type of plan must be created in a matrix form indicating how often you will be communicating to the customer, sponsor, departments, or agencies which are influencing this particular project. The most important thing about a communication plan is a clear understanding as to when and how the communication will be given and what timeline it will follow. Meetings with project customers The project customer normally has more interaction with the projects sponsor than anyone else. In many projects it is not uncommon for the project sponsor to interview and discusses the goals of the project and pass on that information to the project manager and team. The one monitoring technique which can be assisted by the communication plan is scheduling periodic feedback sessions with the customer. This will do several things, such as informing the customer on the progress of the project, as well as verification you are progressing properly. It is very important for communication to take place between the project team and the customer, not just during the initiation phase but throughout the entire project. If this is done correctly, there will be no surprises from the customer nor will the project team miss the desired outcome and goals.

Meetings with the project sponsor Project sponsors normally represent management in viewing the project through that cultures eyes. This means that the projects sponsor normally has a great deal of input and can influence the budget or resources provided to the team. The project sponsor has a great deal of responsibility as they oversee multiple projects and multiple resource packages to complete those project plans. It is very important for project teams to maintain communication with the project sponsor. This can be done weekly, monthly, or in some extreme cases even daily. How often a project team communicates with the project sponsor is determined based on the amount of interaction desired for that particular project. There are several items which should be detailed as part of the communication flow and plan of any project. Each of these items is considered high priority in making sure everyone is well informed and has current information. Update and status on project Getting a current update and status on the project is necessary in each team meeting. In is our experience, we have seen team meetings that wasted 90 minutes and yet did not detail project progress so that people would be able to make the needed decisions. Giving an update status on the project should be the minimum each team member is prepared to do when they arrive at the team meeting. They should come prepared and knowledgeable about their area of assignment and be equipped to defend where the project is and what help they need to move the project forward. One way to make this easier for your project team is to create a standardized status and update checklist form to be used. This form makes sure that each team member is getting the needed information back to the team and is used in organizing and documenting the needed information. Checks on critical path updates You can run a project extremely hard trying to meet every due date, but if you miss critical path dates your project is doomed! The critical path consists of dates which are considered hard dates and then movable. These dates, if missed, make the project late. They are different than an activity task date, which many times has contingency time built in it. Naturally, all dates are very important, but it has been our experience that many project members will track all dates as if they are the same priority, thus missing critical path dates which sabotage their planning. Usually, this happens due to a lack of understanding of the importance of a critical path date compared to an activity or task. This is one of the items that each team member should be trained on during a team session, and the project managers should assist in monitoring to guarantee successful completion of the project. One way to magnify the importance of critical path dates is to separate them into a different type setting or color to make them stand out from the other dates on your project plan. This calls attention to the date and reminds team members of the higher priority of its position. In addition, if you make sure part of your agenda deals with the discussion of critical path dates, your team will begin looking at these issues the same as the project manager. Approved change orders Troubled projects have team members which are doing work in areas that have been changed without their knowledge. Passing along change orders to the team and documenting those changes for future reference is very important to the communication plan. Change orders appear to be a strong source of frustration due to members wasting a great deal of time working on areas that have been changed but never communicated to them. Part of our training with your staff revolves around what to do with change orders. In our experience, change orders must be communicated instantly to the project team. We do this by contacting the team member who has a direct responsibility to that area being changed. Second, we contact the entire team through e-mail notifying them of the change and how it will impact their part of the project. Finally, we point out the change orders which have been approved during the project team meeting. In this meeting, we normally have documentation and questions to clarify. This allows us to make any additional adjustments to the plan or to the team members priority list in order to fulfill these changes. Bottlenecks and work stoppage An additional area that needs to be communicated is the discussion of bottlenecks or work stoppage on the project. It is not surprising that many projects will be on time and budget until they reach a particular department or person,

and then you notice a work stoppage. This needs to be discussed and brainstormed with the project team to develop ways to move the project forward. Some teams in the past never discussed bottlenecks within the organization. These forced the team members to be involved in areas of high frustration with little leverage for moving the project. By adding this discussion to your team meeting, you can leverage the knowledge base and experience of your entire team while gaining ideas for faster application. Concerned areas The last section which should be considered as part of the communication plan is the examination of areas of concern. People mistakenly leave this area out and anticipate the project team will handle these problems on their own without any help from others. Concern areas allow your team to verbalize their frustration, and it keeps you knowledgeable of hurdles they are running up against over and over again. Unless the project team is able to hear these areas of concern, it is possible that they will be missed with the assumption the project is running in a more positive manner than what is true. Transfer of information to other important parties Transfer of information to other parties influenced by this project is very important. It is not uncommon for some projects to function in a vacuum limiting their communication outside of the project team. This type of vacuum is fine if the project is extremely confidential in nature. However, many project teams continue to limit the transfer of information to parties that are very much part of the future of the project. This means that at the last minute they are trying to get others equipped and up to speed with the needed knowledge. Transfer of knowledge is being neglected at such a high rate that agencies are watching knowledge go out the door. Someone might question where this is happening the most. Agency after agency has reported the need to get rid of contractors when budgets become tight. Many of these contractors have worked for the agency for a long time and know a great deal about a specific area. After they have left the agency, it becomes apparent they knew something which no one else knows. The second area we are seeing a lack of knowledge transfer is in retiring employees. Men and women have worked for an agency for 15 to 25 years, and they are now leaving for retirement. However, no one puts a plan into effect to get this person to transfer some of their knowledge over to a person who is remaining behind. This gap is foolish and hurting agencies by forcing them to redo numerous processes and projects in order to educate them. In conclusion, a communication plan is very important in the imparting of the knowledge, data, and information to the entire project. It must be examined, included, and followed.

Lack Of Project Audits To Measure Progress - Project Management Mistake # 11 (#11 in the series 15 Deadly Project Management Mistakes Government Agencies Make Which Cost Them Revenue, Time & Efficiency) By Keith Mathis - PM Expert Live Project audits are very important for tracking and monitoring project progress in a methodical way. Project audits can be used to help drive the project forward while maintaining quality throughout the entire process. In this section we want to examine what should be audited, the timing of audits, who should conduct the audit, and how those audits will be reported.

Discuss areas to audit Audits should take place throughout the entire project. This means that the project team should determine to conduct an audit based on time, budget expenditure, or anything that they are designed to track. Project audits are a means of tracking projects early rather than examination at the end of the project cycle. Some of the most common areas to audit are: Budget Time Phases Level of service Quality Communication Cycle time

Processes Pilot programs Timing of audits Audits can take place at any time during the project. The interval of the audit can be determined and planned by the project team based on feedback desire. For an example, if a project team is having a severe problem with quality in the area of internal customer service, it is possible for that team to conduct an audit periodically to see if the service is getting better or worse. In other cases, it is possible for project audits to take place to determine the quality of a particular product. You see this happen when a project is being conducted that produces a product such as software designers. They will design the product and test it over a period of weeks or months to determine that is working at the most optimal level of quality. In summary, audits can be conducted throughout the entire project based on the timing and sequence needed to provide the data and confidence the project is doing well.

Who will do them The person or persons conducting the project audit are going to be an expert in that particular area. This means that people who have an expertise in quality will normally examine the area dealing with quality. If a person has an expertise in structural engineering, they will conduct an audit in the area of their strength. This does not mean other individuals cannot be part of the audit team, nor does it mean that you must always have an expertise in that particular area. It is possible for people to be very beneficial to a project audit even though they do not have an expertise in that area. They can participate and be beneficial by giving comments and feedback while conducting an audit that is outside of their realm of expertise.

Who they will be reporting to Normally, audits are reported first to the project team and then to all the relevant individuals involved in the project. It is not uncommon for an audit to be reported to the project sponsor, project manager, or internal and external customers to gain feedback, and to give them insights into the level of quality that is being accomplished by this project. In larger organizations, project audits are sometimes tracked by a project management center that has been created by the organization for the purpose of maintaining project quality. This same center will also conduct project management training and encourage certification in project management in order to constantly push skills to higher level. Project audits are very important for tracking and monitoring project progress in a methodical way. Project audits can be used to help drive the project forward while maintaining quality throughout the entire process. In this section we want to examine what should be audited, the timing of audits, who should conduct the audit, and how those audits will be reported.

Performance Appraisals Which Do Not Measure Project Management Skills - Project Management Mistake # 12 (#12 in the series 15 Deadly Project Management Mistakes Government Agencies Make Which Cost Them Revenue, Time & Efficiency) By Keith Mathis - PM Expert Live Each year our instructors are told by participants they have non-performers working on their teams. They express a great deal of frustration because they have little or no power to do anything about it. One example was expressed that even when the team members supervisor talked to the non-performers about their behavior, nothing changed. This creates a crisis within the project team. Can project teams only function affectively when they are supervised by someone who has position power? If so, that undermines the entire process of running project teams across most government agencies. Today it is impossible to have all project teams supervised by someone with position power. There are not enough supervisors or managers to accomplish this task, nor should they be forced to run projects in this manner. Then what can a project team do to run the team as well as monitor performance? We maintain that project teams must have some way of evaluating each team member. This can come about based on two simple changes in the way most agencies are performing evaluations and checks on their staff. The first and most simple solution to this problem is for an agency to redo the evaluation process of each employees performance; include the running of projects as a portion of that evaluation. One simple way to do this is for the immediate supervisor to gather feedback from project managers on how their staff is performing on a particular project. When this is done appropriately, you will notice team members can no longer be a non-performer on a project and still think it will not impact their performance evaluation. What you are

doing is holding the employee accountable to perform not only on those items that are directly supervised by you but also fulfill all the objectives of their job which includes running projects. The second possible way of measuring and evaluating how staff performs on projects is to have each project manager fill out that portion of their individual performance appraisal. This means you would have direct observation from the project manager on how that individual team member is performing. What is the anticipated outcome of this? In most cases, you reduce the frustration presently being experienced by many people in your agency when you have created an excellent feedback system for communicating and holding each employee accountable.

Allowing Turf Battles To Impact The Project Team - Project Management Mistake # 13 (#13 in the series 15 Deadly Project Management Mistakes Government Agencies Make Which Cost Them Revenue, Time & Efficiency) By Keith Mathis - PM Expert Live Turf battles between departments and agencies frustrate the progress of your project team. Teams are being forced to play politics with individuals over turf issues and personal preferences. Some project managers are even unaware of the abuse their teams endure surrounding turf. On one occurrence a manager refused to give information and data which was needed to successfully drive a project forward. This same manager even informed his direct staff that they were not to support the requests being made from a particular department. This turbulent culture slows down the progress of your project and increases your teams frustration. How are turf battles created Turf battles are allowed due to individuals holding jobs for long periods of time and being treated as untouchable. During their tenure they have developed people they do not like and who they have disagreed with publicly. Most people with the agency will disagree, but they will do it in a nice, calm, agreeable fashion. However, others will become bitter, and they never forget it. They harbor the ideas and the situation while playing it over and over again in their heads. Why turf battles are allowed First, bitterness and grudges bring on many of the battles. Since many of these individuals are harboring grudges over past offenses, they have also been employed a long time. This means they have become set in their ways, and they have come to believe they can function in any manner they desire. This is reinforced when these same individuals are given glowing performance reviews each year, which only emphasizes wrong behavior and performance. Second, the natural silo effect within the agency increases battles. I am not talking about confidential or propitiatory information. I am talking about best practices and important information that could affect the project. Some people are fearful in sharing information outside of their silo. Many times the information could benefit the project team and reduce the time needed to complete it faster, but it is still not communicated. Third, there is no mechanism put into place to reinforce the sharing of the information outside of the silos. This makes staff willing to share feel like they are doing something wrong by letting people know some successful project techniques. How it impacts the project team Teams are frustrated with having to go through this type of trouble. One team member indicated he spent his entire time guarding what he said to different people because of all the turf battles. They feel that they are being forced to take sides or represent a side that is not their fight. This situation becomes even more complicated if there are several turf battles going on at the same time. The team members feel they are pushing a thousand pound weight along. Does it not make sense to take fights like this away from your team members and deal with them through the project manager or sponsor ranks? How to deal with them successfully Dealing with turf battles is different depending on the person and the situation. For some situations, simple discussions with all parties involved reducing tempers. However, there are others who have no intention of making any changes or relaxing their demands. They have justified these feelings to themselves and are almost insulted that

someone would even consider asking them to change. The group that refuses to change and loves the fight might need leverage from your project sponsor and upper management. One word of caution in enlisting upper management. This action will get movement on the situation, but it will sometimes prevent repairing the relationship which has been damaged. The first thing to try, in most instances, is talking with the person or persons before going to upper management.

No Close Down Plan Or Post Mortem For Ending A Project - Project Management Mistake # 14 (#14 in the series 15 Deadly Project Management Mistakes Government Agencies Make Which Cost Them Revenue, Time & Efficiency) By Keith Mathis - PM Expert Live One of the great strengths of having your project team trained is how they handle the close down and post mortem of the project. Our trainers have asked countless attendees during each course how many of them utilize a close down plan and a post mortem for ending a project. Ninety-nine percent indicate their agency and project teams bypass this process. Project managers in the position of deciding how to close down a project properly and to conduct a post mortem are hindering the future development that can be learned by not including these two pieces in their planning. The close down plan brings the project to an effective close while handing it off to the customer without any gaps in service, quality, or communication. During the post mortem section of the project, the project team recognizes, analyzes, and documents what has gone right with the project as well as what has gone wrong. Why use a close down plan Closing a project down properly can assist the project team in the following two ways. First, it allows the project team to pass the project off to the customer in a structured and orderly manner. This allows time for the customer to receive the project and to make sure that there are no gaps in service and to educate the customer in ways to maintain the project at its highest level of quality. Second, without clear close down plans, the project team and the project manager might inadvertently leave bills and portions of the project undone. The project close down plan guarantees that the project team is functioning in a structured manner and that they are driving the project to its needed end. It reinforces meeting all objectives and deliverables of the project. Reasons for a post mortem It is rather confusing why many organizations are neglecting to participate in the process of conducting a post mortem at the end of a project. It appears they are very much unaware that a post mortem can assist in being able to create the best practices while also modernizing many of their processes and techniques for future projects. Sometimes project sponsors feel that the advancement of new processes and techniques does not justify the time it takes to conduct a thorough post mortem. It is clear that this level of thinking is more of a myth and is distorting the overall process and success rate of projects. Unless project sponsors buy into the fact that post mortems are effective and that they must be included to determine the success or failure rate of a project, they will not be followed by the project team. Post mortems create concrete data that allow all parties to make decisions that will change the course of future projects and will move everyone away from generalities of measurement to a more precise manner. Post mortems do not need to take a large period of time. Post mortems can take place in a streamlined fashion in which the project team, along with the project manager, conduct a brainstorming activity and analysis of the good, the bad, and areas they would change on future projects. This streamlined fashion of conducting a post mortem will increase the effectiveness of future teams in a quantitative manner. Just for the record, one common change based on this level of data can increase the effectiveness of future projects anywhere from 5% to as much as 33%. This alone justifies the inclusion of it. As a result of conducting post mortems, each team is building the necessary data to create the best practices which will streamline the process in a future project while increasing the efficiency and effectiveness of everyone. This level of understanding reduces the need of trial and error and allows project teams to function using proven processes that have already produced success.

No Creation of Best Practices - Project Management Mistake # 15 (#15 in the series 15 Deadly Project Management Mistakes Government Agencies Make Which Cost Them Revenue, Time & Efficiency) By Keith Mathis - PM Expert Live

Many project sponsors have told us that they have never considered the creation of best practices for their organization. This means that they are forcing each project team to recreate processes and procedures for running the project on their own. This level of activity takes a great deal of time. It does not mean that the way the project team is conducting business is the most effective based on the culture and past performance of the organization. Best Practices Defined Best practices can be defined as a series of standardized processes and procedures for the department or agency. These processes have been deemed necessary to get the desired results in completing the project. Best practices are not something that has been thrown together with little or no effort. They have been thought through and adjusted. How They Benefit Projects Best practices help projects by minimizing the time a project team needs to put together processes and procedures for running the project in an effective manner. They can also assist those overwhelmed areas in the projects and amended team members. Let me suggest you track some projects unofficially for the next several weeks or months. One of the things you can examine is how those projects are running based on the processes and practices of experienced team members. As you examined these projects more deeply, you will determine the difference between a well run project based on proactive practices which have already been tested compared to those used by trial and error. In addition, these practices allow project teams to get up and running in the fastest way possible; while minimizing down time, discussion time, and foolish trial and error. With all of these reasons, one wonders why our project sponsors and project managers are so resistant to creating best practices for their agency. We tend to think that this is done because they do not see the advantage of taking the time and effort to create best practices, nor do they trust the project will be run the same way after it has been developed. What Does Best Practices Look Like We all love to accomplish a great deal of progress in a short period of time. This is the main reason why best practices are so beneficial to a project team. Many people still struggle with what best practices look like once they are developed. Best practices can be a series of checklists, tasks, processes, and problem solving activities used for the purpose of driving a project faster and more effectively only in a shorter period time. Many of our past clients have created best practice manuals for the purpose of passing along this knowledge base to team members and employees. By doing this, they are successfully reproducing their techniques. However, in order for this to take place someone must take control and force the issue of creating best practices for that agency in the first place.

Mistakes and the Blame Game By Jeri Merrell Dont argue for other peoples weaknesses. Dont argue for your own. When you make a mistake, admit it, correct it, and learn from itimmediately. ~ Stephen Covey What is it about business culture that breeds that very special class of citizen the CYA specialist? I have been working with a vendor rep for several years whose focus and follow-through has recently hit rock bottom. This person used to actively manage all our requests and produce results quickly and effectively. Now, they sit on requests for weeks, even months, delaying action and hurting our projects. We want to spend millions of dollars with the company, and we have not been able to make it happen. When pressed, this person fires off blame in every direction. The third parties arent producing. The contracting folks make mistakes on the contracts. The inside professional services teams arent available, or staffing levels are slowing things down. Ive been closely tracking projects, purchases, and initiatives. The delay is primarily attributable to our rep, who is displaying very little focus, zero follow-through and just isnt getting things done for us. Everyone else seems to be giving it their best, compensating for the rep in a fairly high-pressure environment. Weve tried directness, which results in the blame fountain. We documented and attempted escalation, where this person promptly amped up the blame game and started stabbing backs throughout their organization. At this point, we need to either get a new rep or switch vendors. The latter choice would be very, very expensive.

The root cause, here, seems to be someone who seems to be unwilling to learn from mistakes. Where does that come from? Why do people decide that its more important to cover their butts than to get the job done? Why are mistakes considered failures and such an arena of anxiety? Ive always been taught that if I screw up, I admit it, apologize, and do everything I can to fix the problem and move forward. Sometimes, in business, a screwup is fairly minor a mistake on a financial model, an unintended slight to a colleague. Sometimes its huge managing a project that tanks to the tune of millions, or taking a position that gets you permanently branded as negative and obstructionist. Even then, a project management mistake is minor in the major scheme of things. Its not a doctors scary call, or a utility worker bringing down a citys power, or an auto defect endangering thousands of drivers. Regardless of the mistake, though, if you dont admit it and work to resolve it, you never learn from it and grow, professionally and personally. People like this vendor rep never learn, and Im afraid projects and people will get dragged down with them.

Managing Testing Resources: Five Suggestions for the Project Manager - Introduction (#1 in the series Managing Testing Resources: Five Suggestions for the Project Manager) By Cem Kaner and Johanna Rothman Many project managers dont know what to expect from a testing organization. They dont know what the group does, how the product is going to be tested, when things will be done, what deliverables to expect, or how to find this information out. Complicating matters, some test managers want to keep things this way. Weve been successful at managing both development projects and testing groups, mainly for companies that develop and publish packaged software. We see the testing effort as an integral part of the overall process of developing an appropriate quality product on time and within budget. To succeed at this, though, the project manager must be able to see schedules, to receive meaningful deliverables, and to recognize genuine problems, which test groupslike all other software groupshave in plenty. This article is written for project managers, with suggestions on how to work with a test group and hold them accountable for their work on your project. In particular, we recommend that you: 1. 2. 3. 4. 5. assess the risks for your project as a whole; assess the risks associated with the testing sub-project; lay out criteria for important milestones, and stick to them; develop a project plan for the testing sub-project; and track testing progress against the plan.

We are NOT suggesting that you manage the test group. We are not suggesting that you eliminate the intellectual independence of the test group. And we are definitely not suggesting that you should develop these assessments and project plans yourself. What were saying is that the test group provides services to your project, just like the programming groups do (you track their progress, dont you?), just like the documentation group does, just like the other groups that make pieces of the product that you have to release. You have a responsibility, as the manager of the overall project, to ensure that the services provided to you are effective and timely. To do that, you need to understand what will be done, when it will be done, what can derail it, and how those inevitable problems are to be managed. Managing Testing Resources: Five Suggestions for the Project Manager - Assessing the Risks for your Project as a Whole (#2 in the series Managing Testing Resources: Five Suggestions for the Project Manager) By Cem Kaner and Johanna Rothman More and more project leaders are thinking about risk, how to assess risk and plan for it. We cant address that general problem here, but if you could use some starting references to the literature, we suggest that you look at the Software Program Managers Network, http://ww.spmn.com; the Software Engineering Institute, Risk FAQ, http://www.sei.cmu.edu/organization/programs/sepm/risk/risk.faq.html; and the Project Management Institutes Project Management Body of Knowledge, http://www.pmi.org. All that well say here is that you have a challenge when building a product, because you have to trade off four factors:

time to market cost to market reliability of delivered product feature set.

You cant optimize your project against all of these. The product will probably be late or over budget or unreliable or lacking in features. If you manage well, you get to pick which of these dimensions suffers most, and which is held closely to your initial plan. The risk assessment question is, What could happen on your project that would increase your time, raise your costs, keep your reliability low, or force you to cut features? Listing the risks (the what could happens) is the first step in managing them. Managing Testing Resources: Five Suggestions for the Project Manager - Assessing the Risks Associated with the Testing (#3 in the series Managing Testing Resources: Five Suggestions for the Project Manager) By Cem Kaner and Johanna Rothman Assessing the Risks Associated with the Testing The testing part of your project plan has serious risks. Some of our favorite risk questions are:

1. 2. 3.

How non-negotiable is the ship date? Are there fixed dates that must be met for milestones or components of the product? How likely is it that the test group will get the software on schedule? What are their contingency plans if they get incomplete software, less stable than promised, late? For example, can they add staff (competent staff) late in the project? 4. What technical areas of the product do the current members of the test group not understand? Can they achieve a sufficient understanding of them in the time available? If not, what is your plan to ensure that those areas will be effectively tested? 5. Which areas of the program must be well tested? Where can you not afford to cut corners, and why? 6. Are there regulatory or legal requirements that the product must meet? 7. Is the project design rooted in customer research? Is there room for legitimate argument about the goodness of design of individual features? If so, how will you and the test group manage the inevitable wave of design suggestions that come from testers who are often more attuned to customer requirements than many software developers? 8. Some features are so important that shipment will stop if they are not working well. When will the test group do its most powerful pass with these features? Are they planning an intense enough effort? Do they have time to conduct it? 9. Is your test group focused on improving the quality of the product or on proving that youre stupid? 10. How attentive to detail and design are your programmers? Can they accept criticism and use it effectively? What has to be done to make them more productive in their dealing with testers? (We measure productivity in terms of the speed with which you get the right product out for the right customer, at the right quality level.) 11. Discovering and facing issues like these is just one step in running a successful project. You arent going to solve them just by listing them. And you wont solve them all at the start of the project. (Or, for some of them, ever.) Having them clear, though, will help you understand where to focus your managerial attention, money, and time. If you want to ship the right quality product within budget and on time, then you have to protect your project from the defects, delays and overruns posed by these risks. 12. You have to work closely with the test manager in assessing these risks. Otherwise, you are thinking in a vacuum. Even if you have years of project management and testing experience, you are working in a vacuum if you arent working with the people who will have to face the risks that you are trying to manage. You and the test manager may not agree on these risks, on how important they are, or on who should do what to manage them. However, it is very valuable for you to understand each others assessment and management approach.

Managing Testing Resources: Five Suggestions for the Project Manager - Lay Out Criteria for Important Milestones, and Stick to Them (#4 in the series Managing Testing Resources: Five Suggestions for the Project Manager) By Cem Kaner and Johanna Rothman An important tool for managing the project, and your relationship with the test group, is a milestone criteria chart. This lays out criteria for moving the project through different development milestones. How complete is the project supposed to be at a certain point? How should we measure that completeness? These are project-wide issues, and though a good test manager or test lead will gladly help you develop them, these are ultimately your issues to clarify. Brian Lawrence and Bob Johnson present an excellent set of milestone definitions and checklists at their website, http://www.coyotevalley.com. We dont agree with all of their definitions, but thats not the point of their lists. The lists are intended as a starting point and a model. You can customize them for your project. For an alternative set of milestone-specific ideas, see Chapter 12 in Kaner, Falk & Nguyens Testing Computer Software. You can probably find additional milestone lists and definitionsnone will be perfect for your project, but the mix might help you settle on a specific set of criteria that work for you. One of us (Johanna) helped a client develop a set of project criteria and is in a position to publish some of the details. We cant reveal the true name of the company or the product. Here, we call it the Messenger product. Johanna was retained mid-project to manage Messenger and get it released. Johanna wrote in more detail about Messenger in Achieving Repeatable Processes in the June 1998 Software Development. Messenger had been in the market already. This upgrade was of particular interest to specific, important customers. We had negotiated specific, firm delivery dates for interim versions of the product. The product had to go beta in April and it had to ship in July. These customers acceptance of the final version of the new product would depend on our meeting of these dates with the agreed features at the agreed level of reliability. As part of our planning, we developed the criteria listed below. (Note: these are fairly generic criteria. There were some very specific other ones, too, but were not in a legal position that lets us tell you about those. In your project, you will include items that are more specific than these.)

Messengers Milestone Criteria

System Test Entry Criteria

All code must compile and build for all platforms. All developer tests must pass. The code is frozen. All features except tokens are complete.

Beta Criteria

All features complete in code, with developer tests. All code must compile and build for all platforms. All developer tests must pass. All available tests for beta customer must run and pass. All current bugs are entered into the bug-tracking system. First draft documentation is available and shippable to customers. The code is frozen. Technical support training plan is in place, and the people are in place. There are less than 36 open high priority bugs. Ship Beta before April 30.

Release Criteria

All code must compile and build for all platforms. Zero high priority bugs. Document workarounds for all open bugs in release notes. All planned SQA tests run, > 90 percent pass. Number of open bugs decreasing for last three weeks. All Beta site reports obtained and evaluation documented. Reliability criterion: Simulate one week of usage Final documentation ready to print. A working demo runs on previous release. (Performance criterion) At least two Beta site references. Ship release before July 15.

Note that the testing group is vitally interested in these criteria, but the ultimate decision-maker for them was me (Johanna) because I was the project manager. The testing group helped me understand whether the project was meeting the criteria, they helped me understand how to word the criteria and what else should be included. They played an important role. But the list was mine. Looking at Messengers product release criteria, we see a focus on getting to the ship date with a certain set of features, but not a particularly low defect rate. More precisely, several classes of defects didnt matter (as far as the executives and the market researchers were concerned). The overall project reliability had to be understood and reasonable. Specific aspects of the product had to be immaculate. Errors in those areas became high priority quickly. Additionally, anything that genuinely interfered with early use of the product became high priority. Getting ourselves clear on these expectations was essential for successful testing. How could a test group provide support for these very specific objectives if they didnt understand them? Messengers system test entry criteria were chosen as the minimum set that would allow system test to start, even if not all the features were complete. Allowing testers to start early meant that they could find problems early. Every study that we (Johanna and Cem) have seen says that the sooner that you find and fix bugs, the cheaper. We wanted every opportunity to make our dates, and that meant getting good information as soon as possible. The project was a success. We released the beta version two weeks late. We might have released an earlier version, that had been a beta candidate, but it didnt meet our beta criteria. However, we were able to explain our criteria to our customers who had insisted on beta copies, and to explain our status against those criteria pretty precisely. This level of control made them comfortable and they accepted the late release without protest. We also had disputes with the testing group, who wanted to continue testing in areas that we had made clear were not relevant to the

customers acceptance criteria. The clarity of the written, approved beta and release criteria went a long way toward keeping those difficult discussions focused and within sensible time bounds. We shipped the product on time and the key customers were extremely happy with it.

Managing Testing Resources: Five Suggestions for the Project Manager - Developing a Project Plan for the Testing SubProject (#4 in the series Managing Testing Resources: Five Suggestions for the Project Manager) By Cem Kaner and Johanna Rothman To determine whether the project has met the criteria (which is Johannas view of the testing task) or to prove that the product has not met the criteria (Cems view of the task), the test group has a lot of work to do, probably involving more than one person, over a period of weeks or months (or years). Somehow, they have to be able to tell what is supposed to be done, what theyve actually gotten done so far, whats left to do, and when they have achieved a goal or met a milestone. Different test managers handle the planning problem differently. Forget about the incompetents and the turfhoarders and the blame-it-all-on-you experts. Competent, cooperative test managers differ significantly in how they schedule and in how they communicate their schedule to the rest of the company. Weve had success with variants of a method written up by Kaner and we recommend it to testing groups (Negotiating Testing Resources: A Collaborative Approach. Proceedings of the International Quality Week Conference, San Francisco, 1996. Available at http://www.kaner.com.). However, you cant impose a method on a good test manager (you can try, but the next test manager might reject your method too, after the first one quits.) You can ask for clear communication. What should be in the plan Here are some of the things that we think it is fair to request (and expect) in the testing project plan: First, a clear statement about the minimum level of testing that will be done for every area of the product (program plus documentation plus marketing materials plus associated hardware). Some areas will get more than this, but none will get less. What is that minimum? Do you think it is enough? Too much? Second, a description of different levels of depth of testing that will be used in different areas of the program. For example, we often think in terms of four categories:

Mainstream or Normal Use testing works the product gently. The tester tries out the various options but is not intentionally using extreme values to break the product. In mass market software, this level includes a complete verification of the program against the user manual. (For a discussion of the need for documentation testing in mass-market products, see Kaner, Liability for Defective Documentation, Software QA Quarterly, volume 2, #3, p. 8., 1995. Available at www.badsoftware.com/baddocs.htm; Kaner & Pels, User Documentation Testing: Ignore At Your Own Risk, Customer Care, volume 7, #4, p. 7-8, 1996). Guerilla testing involves ad hoc testing done by someone who is skilled at finding errors on the fly. It is one persons best shot at finding bugs. This approach is typically time-limited. For example, to say that an area will be guerilla-level tested, you might mean that this area of the program will receive a total of two days of ad hoc testing, spread across the project. Normally, guerilla testing is done after (not instead of) mainstream testing. Formally planned testing involves carefully thought through test cases that are intended to thoroughly test that area. Depending on your companys philosophy of testing, this might mean a set of test cases that collectively trace back to (check) every item in a list of specifications. Or it might mean a set of test cases that cover all of the extreme values and difficult options and uses of the program (or other product component) in this area. Or something else. It is harsh testing, intended to expose those problems that a customer would find if the area were not tested and fixed. Planned regression testing involves carefully thought through test cases that are run frequently, perhaps every build or every few builds. They are designed to recheck an area of the product that was well tested, to determine whether it is still as stable as it was previously. Developing this test suite takes much longer than the development of the first good plan for testing an area. Here you are selecting fewer tests (or automating many of them), searching hard for efficiencies and for test cases that would be particularly revealing of side effect problems.

Your test manager might use different names and different descriptions. Theres nothing magic about ours. You just need some descriptions that are clear, clearly different, and that cover the options that the test group will actually use.

Third, a list of the areas of the product. The test group will define the areas in its own way. You might help them with this or not. They have to be free to organize their work in a way that works for them, which might be different from how you would do it. However, you should be able to get from them a list of areas that together include all of the things that the testers will test. Fourth, for each area of the product, a list of sub-areas or sub-tasks. This list should be detailed. It should include anything that takes a day (or even half a day) of work. Having things broken down this finely makes it possible to accurately estimate the size of the task and to accurately track how much work is remaining to be done. You might not be able to get this listsome people refuse to estimate tasks this finely, dividing the project into two week phases instead. We would want more than that, but you might not be able to force it. Fifth, for every sub-area of the product, the list should specify how much time it will take to test that sub-area at the level of depth that it will be tested. Sixth, a total across sub-areas. For every major area of the product, how much time will be spent testing, and, overall, what is the level of testing of this area? This list of areas and sub-areas gives you something to review, to negotiate, and to track progress against. If the test group wants to spend too much time on one area, you can ask why they intend to test this areas sub-areas at the levels they have chosen. What tradeoffs are they making? As you come to understand the test groups tradeoffs, you might decide that they really do need more time and money. Or you might persuade them to test some areas less intensely (with your support). Or you might come away with a well-understood disagreement. In any case, the level of detail of the list is what makes possible the calm, task-oriented (rather than pointy-haired-manager-wants-to-savemoney) discussion that safeguards the quality of the product by focusing the most resources on the most important tasks.

Managing Testing Resources: Five Suggestions for the Project Manager - Dont Make These Scheduling Mistakes (#5 in the series Managing Testing Resources: Five Suggestions for the Project Manager) By Cem Kaner and Johanna Rothman Project managers sometimes react with shock when they see an honest estimate of the time needed to do some testing tasks. If the number is too big, you have to manage it. But dont make these common mistakes, which will bite you in the tush later.

Dont pressure people to promise more testing in less time. They cant. Instead, cut time by cutting tasks or by helping people become more efficient. Dont build expectations of (unpaid) overtime into your scheduling. Testers work overtime voluntarily, to make up for lost time or add creativity or depth to their work in order to meet their own professional standards. This is important flexibility, for them and for the project. Dont make them give it up or people will burn out and/or quit. Dont forget to allow time for vacations, sickness, and holidays. Dont underestimate time spent on administration, staff development, and other non-testing tasks. Assume that people attend meetings, spend time on reviews, help people on other projects, write testing project plans (this isnt free, you know) and so on. Stick with realistic estimates of this overhead. Dont expect the testing task list to be complete, even if it is detailed. There will always be late surprises and unexpected complications. Allow a fudge factor in your overhead estimate for this. Dont bet that this is the last version of the schedule. Plan when to iterate the test schedule.

Managing Testing Resources: Five Suggestions for the Project Manager - Track Testing Progress (#6 in the series Managing Testing Resources: Five Suggestions for the Project Manager) By Cem Kaner and Johanna Rothman If the test team has a detailed list of tasks and an estimate of how long each one should take, then every week, they can report progress against this. For each area of testing, how much time was spent and how close is it to completion? Are they spending more time per task than they expected? Because the areas are broken down into specific tasks that dont take many days each, everyone can tell when specific things are getting finished. You are less likely to see wild overestimates of progress, followed by long unexpected schedule slips.

It takes time to create this list and it takes time to track progress against it. The testing budget must allow time for this task or it wont be done. Not only should the test team review their progress every week, the project team can review the relevant milestone criteria every week at the project team meeting. Before system test, review the system test entry criteria, to see if the project is ready for system test. Before Beta, review the progress made against the Beta criteria, and then review the project status against the ship criteria.

Managing Testing Resources: Five Suggestions for the Project Manager - Conclusion (#7 in the series Managing Testing Resources: Five Suggestions for the Project Manager) By Cem Kaner and Johanna Rothman As a project manager, you dont have to know how to test and you probably dont have the right (or reason) to micromanage the testing group. But this group does owe you services that are essential for the success of your project. You can and should hold the group accountable for those services (their quality and schedule) without interfering with the groups work.

Work Breakdown Structure - Purpose, Process, And Pitfalls By Micah Mathis In this article we are going to look at what many Project Managers and Project Management Professionals refer to as the foundation of the project, or at least the foundation of project planning. The Work Breakdown Structure (WBS) is defined by A Guide to the Project Management Body of Knowledge 3rd Edition (PMBOK Guide) as: A deliverableoriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. Wow! That is a lot of buzz words and jargon, but do not worry. It is not nearly as daunting as it sounds. Creating a quality WBS will require a substantial amount of energy, time, and people, but in the end is not rocket science. However, before we get too deep into how to actually create a WBS lets first look at its purpose. PURPOSE: Why do we need to create a WBS for our projects? What purpose does it serve? Why should I waste my time writing on post-it notes and drawing charts when I could be getting my team started on the actual work of the project? Now, I know everyone reading this is a great project manager or team member, so I am sure none of you have ever said comments such as these, but I am sure you have heard them from those other project managers (who will remain nameless). So to answer these questions, lets take a look at what purpose the WBS serves to our project and our project team. There are three reasons to use a WBS in your projects. The first is that is helps more accurately and specifically define and organize the scope of the total project. The most common way this is done is by using a hierarchical tree structure. Each level of this structure breaks the project deliverables or objectives down to more specific and measurable chunks. The second reason for using a WBS in your projects is to help with assigning responsibilities, resource allocation, monitoring the project, and controlling the project. The WBS makes the deliverables more precise and concrete so that the project team knows exactly what has to be accomplished within each deliverable. This also allows for better estimating of cost, risk, and time because you can work from the smaller tasks back up to the level of the entire project. Finally, it allows you double check all the deliverables specifics with the stakeholders and make sure there is nothing missing or overlapping. PROCESS: Now that we have agreed that creating a WBS will be help to our projects efficiency and effectiveness, how do we go about it? First, lets look at what all we need to get started. There are several inputs you will need to get you off on the right foot:

The Project Scope Statement The Project Scope Management Plan Organizational Process Assets

Approved Change Requests - (PMBOK Guide)

These inputs should give you all the information you and your team needs to create your WBS. Along with these inputs, you will use certain tools as well:

Work Breakdown Structure Templates Decomposition - (PMBOK Guide)

Finally, using these inputs and tools you will create the following outputs:

Work Breakdown Structure WBS Dictionary Scope Baseline Project Scope Statement (updates) Project Scope Management Plan (updates) Requested Changes - (PMBOK Guide)

The first step to creating your WBS is to get all your team, and possibly key stakeholders, together in one room. Although your team is not listed as an input or tool in the above sections, they are probably your most vital asset to this process. Your team possesses all the expertise, experience, and creative thinking that will be needed to get down to the specifics of each deliverable. Next, we have to get the first two levels setup. The first level is the project title, and the second level is made up of all the deliverables for the project. At this stage it is important to function under The 100% Rule. This rule basically states that the WBS (specifically the first two levels) includes 100% of all the work defined in the project scope statement and management plan. Also, it must capture 100% of all the deliverables for the project including internal, external, and interim. In reality the WBS usually only captures between 90-95%, but 100% is our goal. Once we have gotten the first two levels set, it is time to launch into our decomposition. Decomposition is the act of breaking down deliverables in to successively smaller chunks of work to be completed in order to achieve a level of work that can be both realistically managed by the Project Manager and completed within a given time frame by one or more team members. This level of breakdown and detail is called the Work Package. Work packages are the lowest level of the WBS and are pieces of work that are specifically assigned to one person or one team of people to be completed. This is also the level at which the Project Manger has to monitor all project work. Now the million dollar question is how specific and small does a chunk of work need to be to still be considered a work package? Well PMBOK does not seem to give a definitive answer on that. Most project managers concur that this varies by project, but can usually be measured using the 8/80 Rule. The 8/80 Rule says that no work package should be less than 8 hours or greater than 80 hours. Notice we said that the work package is the lowest level of the WBS. Activities and tasks are not included in the WBS. They will be planned from the work packages once they are assigned. Now you are ready to start your team on the work of decomposition, but do not get too far ahead of yourself quite yet. As grandpa always said There is no reason to reinvent the wheel. Occasionally, you will run into a project that is a first of its kind, but that is not usually the case. Most of the time, you, your team, or your organization has done a project like this one in the past. That means that there should be a WBS from the previous project that you can use as a template. This will save you a lot time and effort. Even if you have not done a project like this one before, most Project Management Offices (PMOs) have basic WBS templates that can get you started. Another great technique to make your life easier is the Post-It Note Technique. I know it sounds a little cheesy, but it actually works very well. In this technique you simply write each deliverable on a post-it note and stick them at the top of a wall. Then you and your team start to break down each deliverable into components and write each component on its own post-it note. This way, as you place them on the wall and start to create your tree structure, everyone can easily see what has been accomplished and where you are headed. Also this technique allows for easy movement of components around within the WBS. Now the conference room wall is covered in post-it notes and Sally is frantically wanting write everything down before they start to fall, but wait one more step before you put it into an official (or semi-official) document. You can use your newly created WBS to look for missing or overlapping pieces of each deliverable. This will help eliminate change requests and double work down the road. Once that is completed, put your WBS on paper and log it into your project. Many projects will also find it necessary to create a WBS Dictionary to accompany their WBS. The WBS Dictionary is simply a document that describes each component in the WBS. This helps clarify any specifics later on when team members completing the work or stakeholders viewing the deliverables have questions. Also, when creating the WBS for very large, lengthy, or complex projects, all the deliverables specifics might not be known up front and, therefore, it is difficult to create a full WBS. In cases such as these many people use what is called Rolling Wave Planning. This is when you plan down to the level of detail currently known and go back to plan deeper once more

information is acquired. Usually rolling wave planning needs to stay as least 2-3 months ahead of the actual work being done, but of course this varies slightly by industry. PITFALLS: Lastly lets look at five common pitfalls to creating a WBS. If you can keep these few possible issues in mind when you are creating your WBS, you and your team will be much more successful at creating a useful and accurate Work Breakdown Structure. 1. Level of Work Package DetailWhen deciding how specific and detailed to make your work packages, you must be careful to not get too detailed. This will lead to the Project Manager to have to micromanage the project and eventually slow down project progress. On the other hand, work packages whose details are too broad or large become impossible for the Project Manager to manage as a whole. DeliverablesNot Activities or TasksThe WBS should contain a list of broken down deliverables. In other words, what the customer/stakeholder will get when the project is complete. It is NOT a list of specific activities and tasks used to accomplish the deliverables. How the work is completed (tasks and activities) can vary and change throughout the project, but deliverables cannot without a change request, so you do not want to list activities and tasks in the WBS. WBS is not a Plan or ScheduleThe WBS cannot be used as a replacement for the project plan or schedule. A WBS is not required to be created in any type of order or sequence. It is simply a visual breakdown of deliverables. WBS Updates require change controlThe WBS is a formal project document, and any changes to it require the use of the project change control process. Any changes to the WBS change the deliverables and, therefore, the scope of the project. This is an important point to help control scope creep. WBS is not an Organizational HierarchyThe WBS and Organizational Hierarchy chart are never the same thing. Although often similar in appearance, these two documents are very different. The Organizational Hierarchy shows things like chain of command and lines of communication, but the WBS is restricted simply to a project and shows only the deliverables and scope of that project. We hope that this article has helped you better understand the Work Breakdown Structures purpose, process, and common pitfalls. The WBS is an extremely valuable tool to the project management methodology. It can make or break a project. It sets the foundation for the rest of the project planning. A solid WBS helps ensure proper project baselines, estimating, resource use, scheduling, risk analysis, and procurement.

2.

3. 4. 5.

Writing the Work Breakdown Structure By Lisa Sieverts The WBS is a mythic document in Project Management. Every text reminds us that the WBS is the foundation of the project plan. But what the heck is it? Perhaps appropriately, Ive found a lot of mythology on this topic. So lets talk about what it is and how to build it. I should begin by saying that experts differ. I belong to the school of Effective Work Breakdown Structures as outlined by Gregory Haugen in his book of the same name. Thus, we are believers in the deliverable-oriented work breakdown structure. Simply put, the WBS is an outline of all the major deliverables that will be produced as part of your project. The key is that we are talking about the nouns, the (mostly) tangible objects that will be created through project work. Those items about which we can say, once we have all of these things, the project is complete. Most people have trouble with this concept at first. We have often been trained to think in terms of the activities, that is, the verbs, rather than the deliverables or nouns. There are several ways to create the WBS. If youre finding that you are focused on those verbs, then do a sticky note exercise. Write one activity each on a bunch of stickies. Then find a nice blank wall and arrange those verbs so that you can see which deliverable should result from each set of activities. This is a bottom-up approach. Another approach is to begin at the top. Think about the largest categories of deliverables. Usually these consist of things like:

Research Design Construction Documentation

Test Project Management

Then decompose those major deliverables into one or two smaller categories. Thus, under Design, we may have both Database Design and Website Design. The goal is to keep the WBS fairly high level. I dont like to see WBS documents which are longer than one or two pages (which is related to another topic: keep your projects small and manageable). However, you do need to make sure that 100% of the project-related work is represented on the WBS. For example, say you forgot to list Documentation as a deliverable but you know that there will be documentation work that must be done. In that situation, the WBS would not be an accurate reflection of the work and all the future prject management documents would underestimate the resource needs of that part of the project.

Product support manager

Product support manager is an important position in the company, an experienced professional having relevant experience in the industry can perform well.Product support manager is responsible for creating and executing product strategy. Product support manager works in deadlines and it is generally a high pressure result oriented job. Ability to plan the product strategy Meticulously and executing the strategy which aligns with the company policies and goals. Product support manager has got various responsibilities.

Top Eight Responsibilities of a Product support manager

Responsibility to create Product strategy, improve sales and customer satisfaction is the prime responsibility of a Customer support manager and also ensuring that the created product strategy, specifications are carried out successfully. Product support manager has to work closely with other departments which contributes sales to the organization. Getting approval for the product strategy created with the help of higher management officials derive a method for the product strategy to align with the company policies and goals. Product support manager even make marketing calls to targeted customers who really need the companys products/ services explain about the features, benefits etc and convert them as a customer. Ensuring customers are satisfied and also involve in the product support as if any customers faces some issues with the product, Product support manager responsibility is to solve those issues and ensure that customers are satisfied. Researching and finding out new sales opportunities and also finding out new technological improvements that can be made to improve customer satisfaction. Provide an effective communication net between marketing, sales and production department ensuring the product strategy is executed well without any problems. Reporting about the current status of the product strategy to his/her higher grade authorities and also the needs raised by each department which will support the project strategy is one of the important responsibility of a Product support manager.

General skills of Customer support manager

Must have experience and knowledge in working with Sales , Marketing and Production departments. Have strong communication and interpersonal skills to gel with other departments and supervise. Must have all the skills to prepare project documentation Must have good training skills, working closely with other departments and make them work according to the product strategy is one way teaching them what you want from them. Computer skills definitely needed, you need to at least Know Microsoft Word, Powerpoint and Excel.

These responsibilities and skills might vary according to the industry, country.

Responsibilities and Skills required forTechnical Product Manager

Home Jobs, Marketing jobs, Product Development Responsibilities and Skills required forTechnical Product Manager

Responsibilities and Skills required forTechnical Product Manager

Technical product manager is for experienced individuals who have well-versed knowledge about Product management or development. This is a high-paid salary, and the Individual holds a senior position in the company. Technical product manager will be assigned with the following responsibilities.

Responsibilities of Technical Product Manager:

Basically, this work is everything to do with product management, and individual must have experience to do these following responsibilities. Technical Product Manager must have thorough knowledge about the companys products strengths and also should have knowledge about the other competitors for the product.

Ability to develop a new road map strategy starting from the release of the product to the end stage and also upgrade the features of the product which matches with the requirements of the customers who are buying your product. Responsibility to find out the important inputs and needs of the customers about your product through many ways and enhance the product features according to the requirements of the customers. Creating innovative product ideas, which will attract more customers to buy the product. Responsibility is to search and find out new opportunities to market the product. Interact with the other product development team members, such as product designers or product architects and communicate about what the end customers expecting from the product and communicate the changes to the product development team and get it done. After upgrading the product which will meet the customer requirements, the next job is to derive the benefits and advantages that a customer gets when buying the product and also do competitive analysis on various other competitors product and preparing technical documents to explain about how this product differs from other products to the end customers.

Skills required to become a Technical Product Manager:

Most of the top-notch companies looking for Individuals in Technical Product manager are expecting at least 5 to 10 years of experience in Product management. Some companies even offer this position for people who have 3 to 5 years of experience.

A person applying for this job must have some kind of a Business degree, MBA will be an ideal choice for the companies to award you this job. Basic qualification for this job is a bachelors degree. Experience in handling market driven products and the ability to understand the needs of the customer on the base of their inputs about the product. Knowledge about the product development life cycle is necessary in handling this job. Business analysis skills are important for this job and the individual must be a team player. Excellent Communication skills is a must for this job, because the Technical Product manager must communicate the needs of the customer to the product developer team and efficiently upgrade the product which matches up the expectations of the customers.

The responsibilities will definitely change according to the company and the type of economy and country you are working. If you have knowledge in product management and experience you will contribute hugely to the companys credibility in releasing quality products that meet customers demand.