Viewing Posts by Dmitri Ivanenko PMP ITIL
Are You Ready for Your Next Status Report?
Categories:
Leadership
Categories: Leadership
| 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 to Empty Your Bag Full of Issues
Categories:
Risk Management
Categories: Risk Management
| 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. |
Managing Project Dependencies
| 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. |
Integrity in Project Management
Categories:
Teams
Categories: Teams
| 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. |
Preventing Project Fraud
| 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? |





