by Raymond Posch on March 7, 2010
I thought I would briefly revisit roles and responsibilities and the RACI matrix today. In projects and processes, sometimes there may be questions or confusion about who is responsible for what. If work is not getting done and people are pointing fingers at each other, you definitely know that there is lack of clarity about responsibilities.
The tool most often used to help clarify responsibilities is the RACI matrix (or its variant the RASCI matrix). Down the left side of the matrix are activities, tasks, or sometimes decisions. Across the top are the roles, such as Project Sponsor, Project Manager, Business Analyst, and so on. In the cells of the matrix are the codes for level of responsibility or involvement. The level of responsibility of the indicated role for the particular activity can be:
- R – Responsible for doing the activity or making the decision.
- A – Accountable for approving the action or decision and answerable for its result.
- AR – Both responsible and accountable.
- (S) – Supportive by providing resources or other support that helps an activity get done or a decision get made.
- C – Consulted before the final action is taken or decision is made. Input from the role is required.
- I – Informed after the action is taken or decision is made.
- Blank – None of the above – i.e., no responsibility or involvement.
Note that the above use of “accountable” is not the same as “being accountable”, in other words, for being accountable to do something as agreed to or planned. On a project team, you want to collectively develop a project plan and have all team members be clear about activities assigned to them and also be personally accountable for doing them, on schedule if possible. As I’ve said before, that is best done if the team members are committed to the plan — i.e., having expressed their commitment to the project manager or, better, to the team as a whole.
So the multiple meanings of “accountable” is one minor annoyance I have had with RACI in the past, and that must be “taken into account”. :>) But if you want to clarify responsibilities – say about who prepares a particular document and who approves it (or, as another example, about analyzing various options, providing a recommendation, and making the decision) – a RACI matrix can definitely help.
Project success tip: The RACI Matrix is a tool that is helpful in clarifying responsibilities assigned to the different roles on project teams.
by Raymond Posch on February 14, 2010
Part of the project manager’s job is to help the business understand the reality of what the project will take in terms of the time and cost to produce a particular result (i.e., scope and quality). Just like when you shop for a new car, you may think you want all the best features and top quality, but when you see the price tag, you (the customer) may decide that keeping cost below a certain limit is more important than having all those features. Therefore, you decide that less power and less luxury can suit you perfectly fine. You (the customer) adjust your requirements accordingly.
During the course of the project, the project manager must often make decisions based on achieving or maintaining the right balance of scope (what is to be created and its level of quality), the schedule (time), and the cost (resources). This must be done based on the information known to the project.
Base your decisions and actions as much as possible on agreed-to requirements and known facts. Beware of assumptions that may be wrong. Beware of generalizations about what is required. Beware of wishful thinking. Assumptions, generalizations, and wishful thinking are invitations for project failure – goals not met, schedules missed, and budget overruns.
The project manager and team must understand the scope (requirements), people and resources allocated to the project, the work required, and then develop a project plan that you collectively agree will work. Planning does require estimating and making projections, but the more that you know about any constraints on the project and about the requirements for what is to be produced, the better the planning will be.
The ideal project situation is when, during the initial planning stage, scope is well-defined and risks are low, thus leading to projections of time and cost that have a high probability of being right. (Risks by the way are any factors, known or unknown, that can impact the project.) The challenge, though, comes in the less-than-ideal cases when scope and associated risks are not well-defined at an early stage and require significant analysis or discovery.
These kinds of scope/risk problems occur especially when new technology is being used in product development, implementation, or both. Many other conditions, however – such as when the business itself is changing or when the project is high-risk by its nature – can cause difficulty in managing scope, risks, external dependencies, schedule, and cost.
Most projects do not have scope perfectly defined and understood. Most projects, especially large projects, have substantial amounts of risk. So base the planning and decisions, throughout the course of the project, as much as possible on reality and facts. The probability of success goes up when you avoid false assumptions and guessing, and instead make the plans and decisions based on reliable information.
by Raymond Posch on January 31, 2010
Back in December, Glen Alleman wrote a post on his Herding Cats blog about project management maturity. It was entitled “Knowing How Much a Project Costs is a Measure of PM Maturity”, and it was based on a conversation with a client about their IT projects. Some of Glen’s readers had also stated in previous comments that they did not track costs on IT projects, and Glen seemed surprised at the apparent commonality of the problem.
Let me begin by saying that I could not agree with Glen more. Not tracking project costs does demonstrate immaturity in project management. And I would say that not tracking costs is not only common, it is pervasive in IT organizations.
In my experience, IT typically estimates the non-labor costs, and approval of the project is based on those costs. Management of costs in PM-immature organizations is considered a responsibility of management – usually some IT director or the business sponsor – and not a responsibility of the project manager. Those organizations consider the labor of employees on the project to be sunk cost, so the labor costs are essentially ignored. That is, those IT people would have to be doing something anyway, so those costs are not estimated or tracked.
Interestingly, as soon as contract labor or the use of consultants is considered for a project, it is recognized as a project cost, and it is tracked. But again management of those costs is done by “management” – i.e., some director or VP – not the IT project manager.
Usually time tracking by IT staff is not implemented in PM-immature organizations until senior IT management finally realizes they don’t have a handle on how much IT labor is going into projects versus support. Time tracking is often implemented to help get a handle on resource capacity – especially support (of technology/systems) versus projects (generally as a category of work, not specifically).
Once time tracking is in place, senior managers may then recognize that they can have IT staff track time against specific projects. Usually the labor “demand” is first tracked in units of person-hours. When senior IT management sees that IT labor can be measured on projects, it will finally click that “that which can be measured can be managed” for their whole mix of IT projects. At that point, a PMO will typically be established (if it hasn’t already) with the instruction to track actual labor costs of every project and every support function.
But it is not until the IT organization begins to have project managers actually manage a budget of all costs, including the IT labor (and perhaps even non-IT labor) in dollars, that the organization begins moving toward higher maturity in its PM capability. The non-IT labor on projects, by the way, is the investment in the project through its active participation of business personnel in the project.
As a bottom-line take-away, I would certainly advise IT organizations to move toward project management maturity by managing all costs including labor costs. Managing costs improves the likelihood of project success. But, in reality, it seems that most IT organizations usually have to move through a learning curve (similar to the preceding sequence) to understand why they need to manage costs and do it at the project level. Once they have learned the need, they will usually shift the project cost management responsibility from departmental managers to the project managers. At that point, it suddenly makes sense.
How to know you’re adhering to core PM principles
by Raymond Posch on February 28, 2010
Glen Alleman is one of the project management experts who writes articles for Project Success Tips, and he is both a true PM expert and a prolific writer. He cranks out posts on his blog, Herding Cats, at a rate that is astonishing.
I strongly and sincerely believe that the best way to achieve project success is through understanding and practicing the project management principles. But you need to adhere to those principles that are most proven to lead to successful projects.
Principles are far more important, in my opinion, than techniques and tools. If you follow the principles, it gives you much greater freedom and flexibility to apply the principles through different techniques and certainly through different tools. In looking at the spectrum of project management and all that it entails, there are a large number of principles that truly make a difference in my experience.
But there are a smaller number that are central to successful project management. In one of his recent articles, Glen writes about his core 5 principles – and he refers to the 5 principles frequently in his writing – but he not only states the principles, for each one he also describes a “measure” to know if you’re practicing that principle in an effective and practical way.
I recommend that you read Project Management Principles Need to Have Units of Measure – it’s an excellent article and practicing the principles will help you achieve project success.
{ 0 comments }