Sunday, September 16, 2007

Data Speaks, Not Necessarily

The truth is out there. Where? Who knows? Surely the project manager's earned value spreadsheet. ...

... "The most politically savvy employee with the most persuasive arguments - and not necessarily the employee with the most accurate information or most insightful analysis - is deemed the holder of the spreadsheet of truth. " ...


Via DM Review: BI Barriers

Labels: , , , ,

Wednesday, July 18, 2007

Project Early Warning System

If we can detect project problems early, we can resolve them. What's your best indicator? Scope quality, SPI / CPI, QA results? ...

... "In general, the earlier you spot trouble, the easier it is to do something positive about it - anything from making minor adjustments to scope or schedule to killing the thing outright. " ...


Via CIO: Project Rescue

Labels: , , , , , ,

Monday, June 19, 2006

5 Lessons in Leadership

The following Lessons in Leadership were originally presented at a recent CIO Leadership Conference but are also applicable to PM's:

10. Failure is not an option (as per Apollo 13's project leader Gene Krantz)

9. The kind of organization you are in determines the kind of leader you need to be (I'd also add that WHERE the project is in its lifecycle and the level of project experience your team and stakeholders have also matters)

8. A good leader has integrity (e.g., accountable, truthful (including in how you report project status and metrics!), a team player and tough when needed)

7. Don't be lazy. (push beyond your natural abilities - get into the details, get out of your office and talk to people, etc.)

6. Make sure that everyone in your organization can articulate what it is you're trying to accomplish (I've also heard this called "the hymn" (i.e., make sure everyone's singing the same tune, from the same book); if you have a more PC, one-word term, let me know!).

You'll have to wait until later for the next 5...this was plenty to digest in one sitting.

Thanks to Abbie Lundberg, the Editor in Chief of CIO Magazine for the info and insights that she shared in the June 15, 2006 edition. They formed the basis for this blog.

Labels: , , , , , , , , ,

Friday, June 16, 2006

One-Page Project Status Report; Keeping it Brief

There's a great writeup in Projects@Work about project status reports, including tips on meeting format and frequency as well as a format for a one-page status report.

According to the article, there are 5 Project Status Best Practices:

    1. Consistency — The status process should be basically the same for large and small projects, and consistent with their measures of success
    2. Escalation — The status process provides a mechanism for escalation of key issues.
    3. Simple — One page with the ability to drill down for details when necessary
    4. Public — Status is available to all (as appropriate) in order to communicate issues, risks and corrective action measures
    5. Inclusive — All projects are required to provide status on a consistent set of metrics
For busy managers who see loads of project status reports, it's much easier to have a consistent, brief summary of what's really happening on each project. They don't need a dissertation on all the details, nor will they get a clear picture just looking at performance metrics. Much like on a business case, most just want the executive summary. Simpler is better. Less is more.

For those looking to improve their status reports (and their credibility with management), read on...

http://www.projectsatwork.com/content/Articles/231704.cfm

Labels: , , , , , , , , , ,

Wednesday, March 08, 2006

Business Agility: IT Proactive Partner ...

To support the need for business agility, IT must be a proactive partner in engaging with the business. Todd R. Weiss covers the theme at the Computerworld Premier 100 IT Leaders conference. ...

... "Bringing in new technology ideas -- and sharing those ideas early on with users so they can weigh in with what they need, want and expect from an IT project -- is key to delivering a successful IT deployment. " ...

Business Agility: IT Proactive Partner: Via Computerworld Premier 100: IT can pave the way for business agility, panelists say ...

This message is consistent with recent research findings from the IT Governance Institute: (1) IT has a pretty good understanding of the business, (2) IT is not very proactive at exploring new business technology opportunities with the business. ...

... "Observation: A small majority (55 percent) of IT departments always or regularly inform the business about potential business opportunities." ...


Via IT Governance Institute: IT Governance Global Status Report—2006 (PDF) ...

So, here's an opportunity for the IT organization ... Get some early, raw ideas in front of your business partners and start getting some feedback.

Labels: , , , , , ,

Tuesday, December 27, 2005

ITIL: Proactive Problem Resolution through Problem Review Board ...

Incident management systems are a tremendous source of data for proactive elimination of problem root causes. Want to have a significant impact on your IT organization's performance. Combine the problem volume data with effort hours to generate a pareto analysis of effort intensity of incidents. Fix the root causes of the top ten effort-intensity problems and good things will follow. George Spafford explores the role of problem review boards in the resolution process. ...

... "The goal of the PRB is to govern problem management reactively and proactively. This is done through analyzing incidents as they happen, reviewing historic trend data and staying abreast of current industry news and vendor updates. " ...

ITIL: Proactive Problem Resolution through Problem Review Board: Via DataMation: Effectively Using Problem Review Boards

ITIL problem resolution enabled through use of proactive problem resolution boards ...

Additional resources on problem review boards:

Anatomy of a Major-Incident Postmortem: "Once sponsorship has been secured, the first step is to create a problem manager role and establish a problem review board to serve as a process development group. "

Data Quality Problem Report: "Site OPS is not close at hand. Setting the status to Pending PIF elevates the problem to the level of being placed on the Problem Review Board's (PRB) weekly agenda for their attention and further handling. The status is set to Pending DQR for the following situations."

Neuma White Paper: Integrated Problem Tracking in Enterprise Software Configuration Management: "Screening of problems will always be necessary to ensure proper routing of the problem report and proper interpretation of the data fields. It is recommended that a Problem Review Board be established to help review problem data. "

Labels: , ,

Saturday, December 24, 2005

Project Status Reports; Simpler is Better


NEED THE INFO

There's a good article in Computerworld about project progress reports. The key lessons are to know your audience, including what they want to see, how they want to receive the information, and how frequently they want to see it. There's no "one size fits" all approach, and it can vary based on the audience, the type of project, and at what point in the project you are.

One thing that everyone seems to agree on is to keep it simple. The best progress reports are one page, with the option for people to ask for suppporting information if needed.

Here's the full article...

How to Write a Progress Report - Computerworld

Labels: , , ,

Saturday, October 08, 2005

Planning for Project Initiation

Here's another of those questions that comes up during consulting engagements, particularly those where resource planning is an important management process.
Many organisations have a formal point at which a project is recognised as being part of the portfolio. Once a project is recognised as being official in this way, then it gets general visibility - it will have a name, perhaps a reference number, a project manager, a charter, a budget, a place on the executives regular status report, etc.
Frequently there is some kind of gate meeting for those organisations that use a Stage Gate Process. For others there may be a portfolio review committee or perhaps it's as 'simple' as getting three separate VPs signatures. Whatever the method, a common requirement is that there must be supporting information giving some kind of cost benefit analysis and, usually, more detail on probable timing, resource requirements, risk assessment and so on.
This information takes time, effort and resources to prepare. And there can be a lot of time, effort and resources involved. The issue is how does one plan for it when, technically, there is no project. There are three general approaches. Which one an organisation uses depends on its management and accounting practices and priorities.
  1. Start tracking the project from the time of very first idea. Once it becomes 'official', there needs to be a way to include the effort spent in preparing the proposal in the newly approved budget - including the cases where the project gets rejected at the first gate. This approach would be relevant where the organisation is really interesting in total product costs. The problem is that there is no official plan at the outset against which time and costs can be recorded - and this makes resource planning difficult.
  2. Have a specific proposal preparation project with it's own budget and approval mechanism. This would be relevant for major projects and often fits in the context where each phase of a major project would have it's own methodology, plan, budget and approval mechanism.
  3. Have a pseudo project which covers 'early project activities' with resources and budget to do a range of relatively lightly defined activities. In this case there would be little formal connection between the effort for the early project proposal effort and the eventual full project. This approach would be suitable for an organisation where project proposals are fairly simple and the effort required for an individual proposal can be approved under a fairly large umbrella.

Labels: , , , , , , , ,

Wednesday, September 14, 2005

No Earned Value Acronyms for Management

There's a good post on the Defense Acquisition University's EVM (Earned Value Management) Forum suggesting a good format for management reporting.

The submitter, Mr. Roger Mandel, makes a good case for protecting management from the details and acronyms inherent in Earned Value and offering the basics in a report.

Check out his recommended format. Looks pretty good to me...

1. Summary Status: (Stated here are the major facts in bullet format. Statements shall be clear and concise.)

2. Major Achievements & Future Scheduled tasks: (List those major milestones that have been accomplished during this past performance period and those that are schedule for the current or near term performance periods.)

3. Trends: (Stated here are the major trends, as the data indicates. Emphasize the present major problem. Phrase the statements in the form of a question. In a few cases, there may be more than one problem. A good problem statement will be concise, usually only one sentence.) Graphic figures should also be used.

4. Projections: (List the possible projections to the major trends. Develop alternative ways to solve the problem, generally more than one possible solution. Briefly note the advantages and disadvantages of each possible solution. State the projected completion period and total final cost.)

5. Choice and Rationale: (State choice from among possible solutions and the detailed reasons for that choice. State why certain alternatives were not chosen.)

6. Areas of Concern: (List cost accounts of task items that are prominent schedule or cost drivers that could cause significant variances.) Some form of a Stop Light chart could be used for a quick overview.

7. Validity of Data: (Comment of noted discrepancies within the submitted report and any concerns for the validity of data presented.)
See below for the full posting...

ACC: Acquisition Community Connection

Labels: , , , , , , ,

Wednesday, August 31, 2005

Project Management Lessons-Learned; A Lesson Learned

For a good writeup on Lessons-Learned, see this writeup as part of the OGC Successful Delivery Toolkit. The OGC (Office of Government Commerce) are the makers of the PRINCE2 project management methodology and the ITIL (IT Infrastructure LIbrary) service delivery management standard.

The OGC suggests questions that should be asked as part of a lessons-learned report, and raises the importance of reviewing prior lessons-learned at the beginning of all projects. They rightfully suggest that lessons-learned should be collected at a minimum after each project phase (ideally even more frequently - such as at regular status meetings).

They also raise the importance of having a quality control person or process owner be a recipient of all lessons-learned reports, in case standard processes need to be revised.

Lessons learned report

Labels: , , , , , ,