The opening was for a Project Manager to lead projects in building large E-learning courses and associated Learning Management systems. However, as my friend discovered, they needed people who had a background in Instructional Design and/or professional teaching experience! This sort of thing is sort of understandable in high-tech domains, but is becoming more widespread in web-based projects too.

This leads me to think that Project Management as a profession is in danger in the near future – either be tech-savvy enough to write a few lines of code for the project when falling behind or know the business enough to converse with the Business Analyst.

[Reminded me of the scene in the movie "Defiance" - when one of the newcomers to the camp early on is asked what he does, he replies "I am an intellectual". People look at him incredulously!]

What do you think? Can someone be just a Project Manager – someone who can handle an ERP project one day and a telecom project the next?

Related posts:

1. Moving into Project Management? What you can do now
2. Series: Project, Program and Enterprise PMO

Again let me remind you Jeet Kune Do is just a name used, a boat to get one across, and once across it is to be discarded and not to be carried on one’s back

- Bruce Lee, while describing Jeet Kune Do (JKD)

Over the last couple of months, I have been reading a large number of blogs, discussions, arguments, between purists on either side of the “Process fence” as well as middle-of-the-road liberals on what development model is best suited.

There are thousands of successful projects delivered using Agile, CMMI, SPICE, RUP and the hybrids in between, so clearly there is no single silver bullet. That begs the question, is there a single best way to develop software? Increasingly, I feel the answer is No. Even if you decide to go one way due to the needs of the project, it is not necessary to abide by a rigid set of rules prescribed in general by experts in that model.

How then do you decide how to develop software? The answer may lie in adapting JKD’s “The Way of the intercepting fist” philosophy, which, I believe, is closely aligned to Lean “thinking.”

Some thoughts:

• Start with understanding the nature of the project, the clients, the project teams and management needs
• Let this understanding drive the selection of the overall framework. For instance, if the project is to develop against an evolving standard, one of the Agile methods may be suitable. But if the team is not mature in terms of development practices, one of the iterative-but-process-oriented methods like the 2I or RUP may be better
• For engineering practices, use concepts and tools proven within the organization
• For project management, the established way within the organization or PMI’s methodology would be a good start
• Don’t be afraid in discarding practices if they are not useful, but be sure to substitute them with more useful ones. The easiest example I could think of is integration. A big-bang integration is not the norm these days, even in most process-oriented shops, but you can institute multiple daily builds instead of weekly or monthly ones. Another example is using Failure Modes Analysis (FMEA) to drive design decisions in iterations to prevent too much refactoring

There must be a term in psychology to describe this behavior: the moment we associate ourselves with something, we start believing that we must adhere to it 10o%, else the skies will fall on our heads!

As project managers, we must be careful not to fall into this trap, but carry a “toolbox” of practices which can be used in different situations. I am told that successful managers have this toolbox subconsciously, but are unable to spell it out exactly.

What about you? Do you think it is advisable to go with a single system of tried-and-trusted practices or have an assorted toolbox?

Related posts:

1. Practitioner-led Process Improvement:For “sticky” processes
2. PMO Series: Change Management

No related posts.

[In industry jargon, Practitioners are the people who perform the tasks indicated by the process - software development teams, for example.]

Why Practitioners have to participate in process definition? Some common objections encountered are:

• They are not experts in process development
• It is not in their job description or they have other work to do
• If they do it, why do we need process specialists?

While these are valid to some extent, lack of ownership of the very people who have to use the process is the single biggest reason for failure of processes. This isolationist, ivory-tower approach results in processes that are out of touch with reality, do not take into account established practices and a general feeling of “process policing” among the development and project management community.

Most people that I encounter, including die-hard Agile champions, agree that some agreement on how things will be done is necessary when such activities involve many people. A process is such an agreement. When we trust people to develop mission-critical software for us, it is foolish to think that they cannot define an effective way of doing things!

Are you convinced yet? If yes, let us move on and see how we can implement this effective means of defining processes. The title points below are meaningful enough without me trying to elaborate on them.

• Assemble the right team
• Identifying process requirements
• Identifying current practices
• Defining the process
• Piloting
• Implementing

Assembling the right team is probably the most important part of this whole exercise. You need to bring in people of all kinds. You need process champions, critics as well as technical experts.

What about you? You are there to assist them in wording the process, doing the documentation work, creating simple flows and probably to see that process requirements are defined right.

One other thing I have found helpful is to incorporate as many current practices, documents and tools as possible. To do this, you as the process specialist have to talk to people, do the research and generally make it easy for the team to define the process.

A good Practitioner-led process improvement initiative reduces the inertia and encourages others to follow what has been defined by their fellow clan members.

In fact, many guidelines from the SEI show that the use of practitioner-led process improvement journeys lead to sustained improvements in appraisal ratings as well as in achieving project maturity.

Share with me your stories, criticisms and your experiences in the comments below.

Related posts:

1. 3 Ways Your Process Improvement Initiatives Can Go Wrong
2. Process – How to develop one that is not stupid
3. The Model does not matter: Projects and JKD

For those of you who celebrated Thanksgiving last week, here’s hoping you had a blast. For those of you who did not, well, have a nice week

I was reading Josh Nankivel’s How to be a Project Manager in 5 steps and was reminded of the time a team lead who had about 7-8 years of experience, came to me and asked the same question “I want to become a Project Manager, but need more experience. What can I do now?”

Of course, I did not have Josh’s post to point to then, so I gave him some suggestions on what he could do in the next 6 months and sent him on his way. I thought I would share them with you, just in case you have the same question. Oh, and he had another question immediately after his first, “Do you think I can become one?” The answer, dear reader, must wait until you have become one!

Okay, here are some things I told him he could do to gain more visibility and experience, while working on getting the formal education/certification. [My friend could do these things on a smaller scale since he was responsible for development tasks of a portion of the project]

1. Scoping, WBS and Change management

I know, these 3 are related but distinct areas, but the reason I grouped them is that these are related to understanding what needs to be completed and managing that till the end. I was not referring to the entire Requirements Management discipline here, but only understanding the boundaries of what was assigned, breaking them into smaller chunks and managing those chunks carefully.

We often see that once we start design and implementation, there are items that come up due to ambiguity in the specs and we start “interpreting” them. These can potentially become scope creep and hence needs to be watched carefully.

2. Estimation and validation of estimates

The team was asked to go through the assigned work and produce an estimate of time and effort to complete them. My friend was an experienced person and hence could quickly see if some piece of work was underestimated or padded up. Although, he had been doing this for some time, it was until later that he realized that tracking completion against estimates actually gave him more insight into accuracy of estimates.

3. Schedule planning and tracking

Historically, the project manager took the WBS and estimates given by the individual teams and prepared the schedule, which was then distributed back to the teams. In this case, I advised my friend to prepare a detailed schedule and send it with the WBS and estimates. This would enable him to see how much work could be allotted to different people with different capabilities and capacities, how to sequence task, how to adjust for early/late completion of tasks etc.

4. Reporting of project status

The project manager usually had a weekly meeting with all team members and compiled a status report based on different parameters. My friend could do the same – he can simply take the standard status report template and fill it based on his team’s inputs, add his own inputs/suggestions and send it to the project manager. You are right. This is what I suggested to him.

5. Identifying and tracking risks

The risk meeting was a chore to be done and after all, it was a PM’s responsibility. Moreover, the risks were generic and carried forward from project to project!

Of course, there were many things, especially at a technical level, that my friend cautioned his PM about – delay in procurement of the test bed for one week could push back the schedule by 2-3 weeks, licensing issues, less time for reviews or inspections could jeopardize quality of the work being produced etc, but these were mostly watercooler discussions. I suggested that he make this a little formal by entering it into the risk tracker the project had, so that it was interesting and valuable to the project!

I cheated a bit early on in this post – there is another one, but that’s because it is not just relevant to Project Management, but in any work stream. Maintain a personal journal: record every analysis that you made, every decision that you made along with the possible alternatives and record why you chose that, record every mistake you or your team made and why, record how the project manager handled a problem. The single most effective tool to learn something is to learn, try, introspect and learn.

If you were in my place, what would you have said? Better advise? Wisecracks?

Psst: If you are a wannabe Project Manager, read the Zombie series by Derek Huether or if you are contemplating a career move, start with this by Josh

One more Psst: The answer to the question “Do you think I can become one?” is another question, “Can you think of two things simultaneously while talking about a third thing confidently?” If yes, then…See ya

Related posts:

1. Series: Project, Program and Enterprise PMO
2. PMO Series: Change Management
3. Some thoughts on Risk Management

The mild arrows show how you can mature the metric to the next level of maturity. For example, you can use a metric such as project schedule adherence to control the current projects, but when you can capture historical information and apply to relevant future projects, you gain the ability to predict their schedule adherence.

Now that you have some idea of how metrics can be used, take a hard look at your metrics (your metrics catalog, if you have one, can have this field!) and tell us what % of your metrics fall into each category in the comments.

Related posts:

1. Metrics Definition – Gaining Agreement from your Stakeholders – Part 1
2. Do your Metrics report performance or help improve performance?
3. Metrics Definition – Gaining Agreement from your Stakeholders – Part 2

[Oh and if you are looking at an approach for defining Real Metrics, look no further than the Goal-Question-Metrics approach. You don't need to look further than How Do You Know Your Metrics Are Worth It by Derek Huether]

Standard Templates

I can’t stress this enough. Without standard templates for capturing, reporting and presenting, you will be firefighting every reporting period. Period.

Capturing raw data: Have a standard template in a spreadsheet or a tool to capture data as activities are being performed. For example, if you are going to collect information on bugs, use a bug-tracking tool for the entire Defect resolution process. This will get you the information much faster.

Capturing aggregate data: Once you have defined the granularity at which your data is going to be represented, have a standard template for aggregating the raw data into this. For example, if you are planning to capture helpdesk calls and have some categories for the types of help desk calls (hardware, OS, Standard software installation, network, email etc), aggregate the data for each type into this template for the current reporting period. Be sure to keep this information in some sort of a Document control system – this is the heart of your reporting system!

Presenting data: Create a standard presentation template with dummy data and create charts using the dummy data. Play around with different chart types until you are comfortable with the presentation. Most people don’t think about this much and are left wondering why the chart does not show the one point which the audience should notice. There is a wealth of information on the internet and elsewhere on the presentation of data (think Edward Burke), so I’ll not go over it now.

Tip 1: A good resource to determine which chart type suits your data best is at http://chartchooser.juiceanalytics.com

Tip 2: Have a standard template where people can enter data, but cannot edit the charts themselves. People do try to gloss over bad information by using “tricks” such as changing the axis’ values etc. If you have an honest organization, feel free to ignore this!)

When you are finished with creating the standard presentation with dummy data, make sure you drive it by the key stakeholders – those who are going to produce this information and those who will consume this information. Most of the arguments during presentations are around the representation of the information – how it gives incorrect/incomplete picture, the axis values not starting with zero, colors/fonts not being consistent etc. So, ensure you have buy-in on this part so that people focus on the content subsequently.

Bonus Tip: Automate your templates as much as possible, if you are not using a tool. It makes everyone’s life that much easier. Initially, you will spend a lot of time fixing problems with the automation, but believe me, it saves a lot of pain later.

I have tried to crystallize my learning around getting your metrics accepted and implemented. What has worked for you? Do you have any specific templates/resources that has helped you in getting the numbers out? Share with me below in the comments.

Related posts:

1. Metrics Definition – Gaining Agreement from your Stakeholders – Part 1
2. Do your Metrics report performance or help improve performance?
3. 4 different ways to use your Metrics

These are usually quantitative and provide guidance on correctly prioritizing risks (and therefore allocating the planned contingency budgets). One other term that I usually recommend when talking about Risk is “Risk Clarity Date” – a term I use to describe the possible date when more information about the risk becomes known to re-evaluate it.

Typically, projects look at the Risk log every x weeks to go through all the risks and figure out if something needs to be changed – this is not very realistic, since many risks are either time-based or event-based.

For example, if there is a Risk that a software component being developed will not be on time, but this is not going to change unless more information on the actual progress is available.

How do you do risk management? At Project levels only or do you have a Enterprise-wide Risk Management process? Share with us.

Related posts:

1. Moving into Project Management? What you can do now
2. PMO Series: Change Management
3. Series: Project, Program and Enterprise PMO

The second part looked at the role of PMO in setting up and monitoring Change Management processes and activities.

The third part discussed the Quality Management responsibilities of a PMO and provided a table of contents to a Quality Management Plan

This post shares some information and experience on how the PMO can review projects and what to focus on in such reviews.

One of the most important functions of the PMO is to periodically review projects, to be able to answer the  following questions:

1. Where is the project wrt where it should be?
2. Will the project deliver on its objectives – timelines, quality etc?

We have all worked on projects, where the status is green for weeks and even months and suddenly moves to  “Red” one fine day.

The best early warning system is effective and in-depth reviews by the PMO for each project in its portfolio. The frequency of such reviews depends on:

Size of the project

If the project is large and complex, one review meeting with all stakeholders is not effective. There is usually too much discussion on some items, especially those that are over the tolerance levels, while routine ones are not given much time. Instead, multiple reviews with separate teams will provide the necessary focus and insight into that area.

Separate reviews also help you to validate information being provided by one team with others. with a single meeting, contradictory statements are not voiced due to fear or a desire to avoid conflict.

If the project is small or medium sized (<30 – 40 people and less number of cross-domain teams), a single review can be effective as all stakeholders can present information quickly.

A typical review should not be more than 3 hours, as information overload sets in and people become mentally tired.

Criticality to business

Review depth also depends on how important the project is to the business. For example, a public-facing market solution will need to be monitored much closely than a project for generating MIS reports.

Current status

• If the project is progressing smoothly, with interediate deliverables on time and within quality limits, you may want to schedule a monthly meeting with offline status reports weekly.
• If the project is just about surviving, weekly reviews are necessary to tightly control the ship.
• Iif the project is behind on timelines or there are escalations from customers (can be internal such as marketing, end-users etc), day-wise monitoring may be required.

This does not mean having long meetings everyday, but you may request for daily status reports to be circulated to the governance team, with meetings held twice in the week.

What should you review

At the minimum, the review should focus on

• Verify status of tasks with respect to the Plan
• Reviewing Key accomplishments during the reporting period
• Understanding key deliverables and activities during the next period and the progress on them till now to determine if they will still be met. A good way to do this would be to ask for Estimated time to complete in-progress activities and verify against the plan
• Check for Dependencies for the upcoming activities to see if there are any impacts due to external and internal dependencies (such as staff from another team, software or hardware availability etc)
• Status of top issues and any new issues added
• Status of top risks and any updates to the Risk profile
• Change requests created/modified during the period
• Quality indicators such as defect trends, incident escalations etc

How to review effectively

• Instead of having a template which can restrict information, ask the project to develop something incorporating the above. The main point of this is to ensure they don’t feel constrained to report in a manner they feel uncomfortable with
• The report can be simple to start with, but must be able to provide enough information for the PMO to decide on the true status of the project.
• Status is usually shown in Traffic-light symbols, but this generally is not accurate or atleast consistent. Insist on objective criteria to determine what is yellow and what is red.
• Watch for tasks that rapidly change in progress completion, especially ones that slide downwards.
• When people use vague qualifiers like “I think it should be done in a couple of days” or “I believe we are on track”, look at start and end dates of the activity to gain an idea of the effort consumed. Ask for time to complete to gain a true understanding of the remaining work
• A major factor in missed deadlines is underestimating the time it takes to solve operational issues. A solid issue management mechanism will help PMO understand the blocking issues that could impact the delivery
• How is product doing with respect to Quality? Are defects being captured accurately? Schedule and review external audits that verify this one process specifically, since defects may not always be reported under the belief that they are minor
• Take the time to review customer feedback, if any and see how it dovetails into the performance of the project
• Periodically reviewing risks is one of the most important tasks of the PMO. Risk profile must be kept updated when more information is received on a subject that is impacted by a risk

Important Note:

The critical part, I cannot overemphasize this, is that the project must feel that the PMO will do anything to help the project solve issues and move forward. This may mean releasing additional funds or add experts for short durations to solve problems. If the project team feels that the PMO is only reviewing/policing, it will find ways to hide information.

You can find an example of a status report template (and some other good ones) at Derek Huether’s blog Critical Path.

Conclusion

A project review is a good opportunity for the PMO to demonstrate leadership to the projects. Transparent communication, accountability, decision-making and support are necessary elements to conduct a good project review.

What’s your take? What have I missed completely? Do you have something more to add?

Related posts:

1. PMO Series: Quality Management
2. Series: Project, Program and Enterprise PMO
3. PMO Series: Change Management

The second part looked at the role of PMO in setting up and monitoring Change Management processes and activities.

This post looks at the Quality Management/Assurance responsibilities of the PMO.

Quality Management is a less-emphasized function of the PMO. In large IT organizations, primary Quality guidance is provided by a centralized Quality function and actual implementation guidance by the PMO. For smaller IT organizations, the PMO.

However, it is important that the PMO incorporate the Quality Management aspects into its guidance and governance systems, since process-orientation can bring in discipline and streamline all activities in the Programs/projects.

The key responsibilities of a PMO for Quality Management include:

Setting up quality standards if none exists or tailoring organizational standards
Provide guidance on defining acceptance criteria to measure successful completion of the project
Provide guidance on setting up Program and project specific metrics for monitoring, tracking progress and quality
Schedule, conduct and review Program and project audits to ensure they are following the guidance provided by the PMO.
These aspects can be detailed out in a Quality Management Plan. A well-structured QM Plan can help the Program/Project adhere to the accepted practices in their projects. In addition, the PMO may also provide
Quality management support to projects through a dedicated team of people.

A typical QM Plan will have the following Table of contents (sections):

• Reference to organizational processes (if available)
• List and reference to any adaptations to the organizational processes, templates and checklists
• List and reference to program/project specific processes, templates and checklists
• List and reference to all standards/guidelines (including technical, industry-specific regulations, domain etc)
• Release Reviews performed by the Quality function before any customer/production release
• Program/Project specific metrics and tolerances
• Work product reviews that will be performed by people in the Quality function
• Tools and techniques used for Quality activities
• Defect prevention, causal analysis activities and techniques
• Reports and Dashboards
• Frequency and timing of project reviews and audits by the Quality function

If you have implemented the Quality Management function as part of the PMO, we would love to hear your experiences and challenges.

Related posts:

1. PMO Series: How to Review Projects
2. Series: Project, Program and Enterprise PMO
3. PMO Series: Change Management