Results tagged “Dmitri Ivanenko” from Voices on Project Management

Project management may not be all about document management, but it's a necessary and important part of the job. And it all starts with the project definition documents created in the planning phase.

As the name implies, these documents outline the details of a given project, such as business goals and requirements, scope, budget and project management plan.

Project definition documents should include:

Basic project data: Goals, objectives and any business issues to be resolved

Project execution parameters: Definitions of project boundaries, key policies and procedures that are specific to the organization and that must be followed to integrate the project work and its result into the organization during and after the product delivery

Required project management methodology: Governs how the project is planned, how each phase is executed and what's required to move from one phase to another

And don't forget any other information that might be helpful to anyone who wants to know about the project.

What's great about A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is that it offers project managers an idea of what should be included in the project management plan. Project managers can then create various project definition documents that best the the project at hand.

What tips do you have for putting together project definition documents? Are there certain processes you always follow?

Effectively planning a project timeline starts with gathering the appropriate inputs to develop schedule process. And spending the time to carefully plan the activities, sequence them, define durations by gathering this data from performing resources, build resource calendars and get estimates is critical to the project.

 

It ensures a great start, good data and estimates that are better than just an educated guess.

 

But, I often find many holes in the scheduling exercise.

 

You have to deal with a lot of details about the activities being planned, the maintenance windows, resource availability (or unavailability), the timing and sequencing of activities, the amount of detail we have vs. the amount we actually need, etc.

 

I find it helpful to map out key activities on a wall, with the critical path being set and clear. Then I break the activities down and put the similar chunks of information together.

 

You don't always get a complete picture of the schedule--it's a progressive process. And you sometimes you miss some things when you don't visualize all the steps that you have to go through. But it fleshes out the dependencies and the risks.

 

Of course a lot depends on the project itself, how much information is already available and how much knowledge the person who does scheduling has about the technical side of the project itself.

 

Many project managers tend to bypass this process or minimize it and leave it to the day-to-day "figuring out" process, rather than planning the scheduling sessions with the team. That reduces the quality of the overall plan and forces the project to go through more changes than it has to.

 

Controlling the project schedule is a process that is done a lot easier when the upfront work is done. Coupled with accurate reporting on project status, the schedule can be easily adjusted and kept up to date and relevant, without constantly re-baselining the schedule.

Reporting project status can be exciting--or can be one of those things you'd do anything to avoid.

By conducting frequent, but relevant and appropriate status reviews, including the stakeholders in the process and presenting fact-based information, you will help to avoid any unpleasant project surprises.

To make the reporting process run smoother, project managers should consider these elements when preparing their reports:

Timeliness: This is all about the reporting cycle, the aspects of "when" and "how often" you report. Pick times that will most benefit the stakeholders.

Fact-Based Information: Validate information before it's reported to the stakeholders and produce trustworthy reports that others can base critical decisions on. These steps help gain stakeholder confidence and contributes to the overall success of the project.

Relevance: Know whom you are reporting to and what information is relevant to that stakeholder.

Appropriateness: Be aware of any sensitive information that should be presented only to specific individuals.

Presentation: Spend a little time identifying the medium - such as handouts, e-mail, verbal, telephone -- as well as the method -- free form, discussion-based or single-person, etc -- for the report.

Knowledge: When you don't have the full details on information to be presented, invite a direct resource that produced the result to the presentation.

Audience: Focusing on specific individuals or groups allows you to provide relevant and appropriate information.

By considering all of these elements, you can present a clear picture of the project's status to the necessary attendees.

Time and again we see projects with a trail of issues that, if not dealt with, build up into this "issues bag," as I call it. The further you get into the project, the bigger and heavier the bag becomes--making it harder to control.

Carrying around these unsolved issues creates several risks.

1. Schedule risks: The project isn't completed on time because the issues left unresolved have caused delays in project activities or phases.

2. Budget risks: An unresolved issue creates a requirement to redo the work. If this work isn't done within the allocated timeframe--when it's still possible to refine requirements and while keeping the changes within the scope of the project--any changes would require additional funding.

3. Staff risks: The issue, if not dealt with by the project team, may be passed on to the baseline/production support team. This would impact other departments--and their time and money.

So how can you make sure the issues bag is empty at the end of the project? Here's what I suggest:

•    Keep track of the issues.
•    Maintain a list of the risks involved with these issues.
•    Keep a list of assumptions about what? and validate them.
•    Maintain a list of all changes executed during the project.
•    Perform quality assurance and close-out any outstanding quality? issues.
•    Ensure appropriate user-acceptance testing phases and garner signoff on the testing.
•    Pay attention to the organizational and business environment your project is impacting and any issues that arise.
•    Notify systems support teams of any impacts that may be caused by your project, directly or indirectly.

Projects don't run in silos or in a vacuum. They run in organized, chaotic environments where everyone is working toward the end result. There's nothing wrong with that--it's how organizations achieve multiple results in a short period of time.

The key, of course, is to manage all these changes and interdependent projects.

But what if you are part of a project that's not a part of any program or portfolio with an assigned program or portfolio manager or director? How do you manage those interdependencies that are not part of your scope?

In my view, it's a matter of paying attention and linking yourself to three key areas:

•    Organization: Culture, processes, standards, rules, events, special blackout periods, etc.

•    Operations: Operational teams responsible for change management, incident management, delivery and quality management/control

•    Project Delivery: Such as a project management office or a business committee or unit that's responsible for project delivery

No matter what dependencies may exist, they will be manifested through these three main channels.

Acting with integrity with other project team members implies being honest with them--and clear about your expectations, intentions and opinions of the work they do.

As a project manager, one has to have integrity in order to sell to the project team the need to succeed and deliver the project on time, on budget and within the scope of the project.

Not only will the team members buy into the plan of action and your project management methodology, they will also become a solid extension of you and remain committed to going out there and getting the job done.

Here are three tips for acting with integrity:

Be Impartial: Be fair and objective. Listen to both sides of the story, various opinions, without attaching oneself to any specific one due to prejudice or favoritism. Objective decision-making fleshes out the problems and allows teams to get to the bottom of them rather than patching them.

Be Thorough: Finish tasks completely, in a comprehensive manner. I find that being thorough in project planning activities means evaluating project requirements and any gaps in details. It also means validating steps against the chosen project management methodology. This ensures a much more comprehensive project management plan and that supporting documentation is produced.

Be Focused on the End Business Result: No matter when team members are introduced, they should verify--within the scope of their project role--initial business requirements and the work that is being requested of them. This allows them to provide their own input based on their subject matter expertise and strengthens the chances for project success.

Have you ever experienced project fraud? Examples include:

Time theft: Team members charging for time they didn't spend on a project or overlapping time on multiple projects

Resource theft: Loss of physical resources, such as software or hardware, or use of project resources for activities not in the project scope

Conflict of interest: Any kind of subcontracting to or employment of resources based on friendships or connections rather than skill sets required for the project

So how can project fraud be prevented?

One way is to have clear policies and procedures for resource utilization, and processes for timesheet management, recording, charging and justifying time.

Implementing internal controls for managing and reporting on project progress and utilization of resources can also help.

Many elements of fraud cease to exist when you use weekly report cards on key project reporting elements: budget, time and scope. Reporting on resource usage based on project activities can show and account for time charged quickly and with clarity as to where and how resources are used.

Keeping track of the entire project inventory with a systematic approach can reduce or eliminate resource theft. Sometimes it's a matter of implementing processes that simply do not allow for resource misappropriation. For instance, sometimes it can be easier to manage consultants than members of the permanent staff. Why? Because there's a forced process to account for time spent.

Some organizations also require permanent/full time staff to report time spent on projects. This allows for a more controlled use of time, as resources, regardless of what field they are working in, will be accountable for the time they put in.

What other types of project fraud have you seen and what are your recommendations for combating them?

In Abraham Maslow's hierarchy of needs, the lowest level consists of basic needs we all have, like air, food and sleep. Once those are met, we begin to move up the hierarchy to higher-level needs, such as safety and esteem.

The same hierarchy applies to the project teams, which are comprised of people with various levels of needs.

We often assume everyone is at a level comparable to ours and our remarks or comments will simply be understood the same way we would understand them. This is not to say the age or experience of project team members is directly related to these needs, as even most experienced members of the team may have gaps in fulfilling their needs.

Whether it's the need of a job or of recognition, all of these needs influence behavior and it's important to be attentive to them. They can influence various project activities and their outcomes, such as meetings, conversations, use of resources, vendor relations, compliance, ethics and fraud.

When organizations recruit project talent, they look at skills and experience as well as personality and cultural fit. But attention should also be paid to team member needs, including those of the project manager, director and sponsor. Doing so can contribute to better understanding of the project environment and the elements that will require special attention.

Many years ago, I recall being in an interview where the recruiter asked me if I knew what visualization was. I didn't. She explained to me that it's all about forming a mental picture of something you want to achieve as if you've already achieved it.

For instance, imagine a standing ovation for excellent project performance or a big increase in pay or a promotion.

It makes the future seem clearer and it tells your brain that you can do it, you can achieve it--because you've seen yourself do it successfully before.

So how does it work? Simply do the following:

1.    Choose an object and really focus on it. Then close your eyes and in your mind, tell yourself what you just saw--the colors, shapes, details. Open your eyes and confirm.

2.    Close your eyes again and see yourself performing activities tomorrow, simply replaying in your mind what you know you will be doing tomorrow.

3.    Identify one thing that you want to achieve. Let's say you have a meeting to present a project status report to the stakeholder community and you want to ace it. Close your eyes and visualize yourself standing in front of all the people attending your meeting, confident of the material and how you presented it. See yourself reporting with confidence, referring to documentation on slides or handouts, seeing everyone around understanding what you are presenting and being pleased with your results.

4.    Do that a few times until you know exactly what you need to do to obtain that success. I would go as far as spending 20-30 minutes a day to do this exercise.

Your mind will become conditioned to visualize the future the way you want to see it and, sometimes intuitively, that will lead you toward the envisioned success.

So my question is: What do you want to achieve now?

Risk exists at all times. The less planning we do for it, the higher the chance of failure or uncertainty of results.

I am a strong believer in integration. Therefore, risk management must be an integral part of any organization's project management methodology.

Risks are generally identified, assessed and quantified. Risk is then monitored until it is no longer a risk or to ensure that any events identified as a risk do not actually go unanswered. That's where risk response comes into the picture.

Response to risks comes in the form of:

-    Acceptance
-    Rejection
-    Mitigation

Organizations must ensure they:

-    Identify key risk-management processes to map them out to the organization's processes for project delivery
-    Identify risk factors (i.e., elements that cause probability of risk occurrence to increase)
-    Standardize risk identification, assessment and quantification, and documentation across the organization

Think of it this way: Risk equals money. It's the amount of money we are going to spend (or not spend) on either activity A or B. If we identify a risk of executing activity A for a price of X, but have a moderate to high level of confidence in success of this activity, we may choose to forgo doing anything else or delay the activity to remove or reduce the risks.

If risks end up being realized and we end up facing the results of it, the cost of it would be linked to loss of revenue and added support to resolve the issue that was created by unresolved (but accepted) risk.

And if it is less expensive for an organization to actually accept the risk and deal with its impacts rather than continuously applying resources to making things perfect, then the justification of taking risk from financial standpoint can be very convincing.

How do you work with risk?

Organizations that have a project management office (PMO) show they are moving toward a centralized management of project resources and strategic alignment to business goals.

But I find a certain level of readiness has to exist in an organization for it to create the platform for a worthwhile and cost-effective PMO--the type of PMO that contributes to the business not by simply being an extension that offers extra resources, but that works and evolves with the business.

There are key issues in organizations that usually hinder this:

•    Senior teams do not understand the PMO or its purpose
•    Senior management teams do not understand what project management is all about and how it can help them lower the costs of implementing projects
•    The PMO is viewed as something you install without careful and business-aligned planning

In my mind, PMO implementation must be viewed and managed as a project. A company should know why it's seeking to implement a PMO in their organization, what business issues it's trying to fix and what inefficiencies it's trying to improve.

A company has to consider:

1.    Organizational Readiness
Organizational processes will require changes to ensure the process flows into and out of the PMO are integrated into the organization.
2.    Cultural Readiness
The organization has to assess its readiness based on current resource pools, whether the resources can be migrated to PMO teams, and how other members of community will be able to align with PMO requirements based on their knowledge, experience, skills and mindset.
3.    Strategic Alignment
The goal is not just to have another department, but to have a team of people agile enough to act quickly and in a focused manner. And planning of the PMO has to include reasons that align with direct impacts on strategic goals of the organization.

Recently I had a team meeting to discuss lessons learned from a project and how we could document them to help reinforce the positive experiences and avoid the negative ones.

As expected, we had a template to document the lessons. We had one team in the room and other teams on a conference bridge and two hours to get it done. Of course, that came with pizza and drinks.

How do you manage to collect, assess, validate and populate data in a two-hour window? You have to have this data already present and entered into the system of some kind (whether it's electronic or paper), with such parameters as experience rating, failure points, links to deliverables each item refers to, impacts etc. And you have to have this information ready and available for this special meeting that simply reviews the results of what you've gathered over the course of the life of the project.

A system of lessons learned would include or require the following:

1.    Lessons learned as one of the deliverables of the project

2.    Method/forum for submitting lessons learned to the project management office or senior management overlooking the project or running the functional areas that require changes based on lessons learned

3.    Method or process for integrating those lessons into the organization

4.    Method of entering the information, such as electronic lessons learned system (web- or network-based) or collection of documents, spreadsheets etc.

5.    Method of accessing lessons learned information from past projects, relating to specific areas of the project or organization

6.    System to have these items as required components of milestones on the project plan

7.    Contribution to the lessons learned from issue reviews in a semi-automated way, so that at the end of the issue review or steering committee meeting you could use the data to post it to the lessons learned system

Success of a lessons learned system depends on a buy-in from the sponsor, the steering committee and the organization to all the items above.

Have you implemented a lessons learned system recently or participated in a lessons learned review? What was your experience?