Monday, July 28, 2014

RACI: Errors and Implications in building the right one

Earlier in the blog, we had discussed about an overview of RACI. It is a great tool in every project and is an important tool in the Portfolio, Product, Program, & Project, Management Office (Shall we call this now P4MO). Too often, however, not knowing how to use this tool is like having a wrench used when a screw driver is needed, leading to the tool’s failure. So, let me address a few key observations based on my experience working with people that apply the tool incorrectly. I would like to come up with a list of 8 key findings. These are listed in no specific order as follows.

Number
Challenge
Possible Problems
1
Too many R’s
This is the person that does the work! If there are too many persons involved, then, the task is adequately defined leaving ambiguity in the task. As a result, many people are required to perform.

Now, agile team may think the work effort is shared in a self-organized team addressing central dependency of failure. This is quite understandable, but then, there should be a fewer R’s. Per design, an agile team should not be more than 7 in total including the scrum master and product owner. So, if you see 3+  R’s for a task, then, trouble is brewing!
2
Too many A’s
This is the person that is answerable to the management and resolving impediments for the team when there is confusion! Too many A’s is an indication of chaotic control. It is like everybody wants to be engineering the solution but nobody is leading.

This could also be an indication of lack of knowledge in the groups expected to be held accountable that holds the “R’s” accountable. Agile addresses this concisely by having the product owner ultimately accountable for prioritizing the user stories, decision making in the iteration backlogs, and in grooming the backlog.
3
No R’s
This is an opposite extreme of an earlier problem and is equally severe. There is no one to do the work! One may associate this with the “anybody could have done the job but nobody did the job” because no one was held to it.

This is a severe issue with the project management particularly. It is possible to have this issue when a task can’t be associated with anyone because the organization has not provided a structure to it. Then, this is something that the project manager has to identify in the risk register and follow through to get a closure.
4
No A’s
This is an opposite extreme of an earlier problem with much severe risk exposure. There is no accountability for any work done leaving to anything being acceptable leaving the customers feel the pain.

This issue presents itself in the internal team members having multitude of meetings to figure our solutions leading to lack of productivity. When this happens, there is a “Skill/task” alignment mismatch potentially.

In my humble opinion, this should not be associated people’s morale due to trust erosion or due to organizational challenges. If any such thing existed, then, the organization must step up to ensure that the accountability is properly addressed.

No customer (internal or external) should be waiting on decisions or success/failure requirements of a task as this is fundamentally against the lean principle.
5
Empty spaces
If this observation exists, then, the RACI is incomplete. If this really happens to be the case, then, the project manager or the person listed as “responsible” and definitely the person listed as held “accountable” should be raising their voice. If a comparable entry in the risk register is absent so that this can be resolved, this is like an accident waiting to happen.
6
Mixed letters
Occasionally, it is possible to have an accountable function along with responsible function. For instance, an internally facing project manager also accountable to talk with the client. However, such occurrences should be very minimal.

It is however not acceptable to see such occurrences in some areas for tasks like “development and QA” or “QA and deployment” because this would defeat the purpose of role-assignment matrix (RAM). If this exists because of resource constraints, there should be adequate process control. Combined with resource constraints and process gaps, this is a potential for “Quality failure by design” and is also, I believe, a means to “Escaped defects.”

I also think that by definition a “R” and “A” are both “C” and “I” to a large extent. But, listing “CA” or “IR” is an issue because then it raises the question of whether the person is first consulting and then accountable? RACI should avoid such ambiguities and should be a birthplace with mixed responsibilities.
7
Lots of C’s
If too many C’s exist, then, I believe 3 potential problems may exist. 

The first one is that there is a skill/task alignment with people listed as responsible/accountable leading to decision by committee. No ownership exists and people are simply trying to cover their trails. 

The second one is that the culture or project itself may be so risky that a number of stakeholders may want to weigh in and potentially slowing down decision making and unnecessary escalations (needless to reinforce here the number of communication channels that exponentially increase here). 

The third one is that the underlying processes and tools are neither understood or clear requiring more conscious checking of “Am I doing it right?”

It is critical for an organization to review the RACI in such cases and address these concerns with an iron hand.
8
Lots of I’s
This issue may not be as severe as Lots of C’s but may be attenuated in some departments. However, it must be acknowledged that “being informed” is to be addressed in the communication plan of a project. At times, the person listed as “I” may have to promote to “C” so that no project gets derailed at times of scope creep, technical debt management, quality issues, customer concerns, etc. It is critical to note that the project consciously address the “I”s balancing the unnecessary slowdown but mitigate any derailment to a project by misinforming a stakeholder.


As you can see, developing RACI correctly is both an art and science. It is an important tool that comes to the project’s aid and should be developed with the utmost care it deserves for it to later benefit everyone that is part of the RACI chart. Wouldn’t you agree? 

Monday, June 30, 2014

RACI: An important tool to manage project outcome and stakeholder expectations

A few years back in a 2-day workshop on organizational strategy to structure, I saw the facilitator came up with the RACI chart and fumble on the RACI explanation confusing “A” in RACI to “Aid.” In a different situation, the vice president of a client management group was referring to giving copyrights to his manager for coming up with the RACI model. Recently, when I saw the RACI matrix for a process map on a sales-to-execution role definition, I saw processes where same owner was both responsible and accountable and some areas where there was no person was identified as accountable.  The more I am in management, the more I am feeling that key important stakeholders should become trained on fundamentals of project management, such as the tools associated with Project Management, so that they can position the projects for success and even inadvertently don’t derail the projects.

There are several reasons to why a RACI chart is required. The most common ones include when the organization is large enough that simple project communication tools alone would not eliminate role ambiguities efficiently controlling costs to the organization. The subtle reasons for requiring a RACI becomes essential when the organization is silo-ed where several members are working on similar tasks creating waste and not making the organization lean. From a project, program, product, & portfolio management perspective, this RACI tool surfaces to the top of managing risks to these strategic initiatives as middle management wonders if they have the authority to implement their job or projects experience schedule slippage, scope creep, cost overrun, and escaped defects.

So, how does this managing strategic initiative from project to portfolio management?  Now that we realize the importance of the tool, let us ground our thoughts here in relating this tool to stakeholder and risk management. Here are my thoughts!

Role
Description
Stakeholder
Responsible
The individual performing an activity.
This person does the work. It may be a developer, tester, data analyst, or network administrator in software development or a project manager in a project.
Accountable
The individual ultimately accountable.
This person is answerable to the management in managing the client and the project’s profitability. An account manager, product manager, project manager, executive sponsor, functional manager are all examples. This person should also use risk register effectively by mapping the risk owner to the RACI.
Consulted
The individual required to offer input and contribute to the activity.
This person offers 2-way communication and is the expert. This person should hold both “Responsible” and “Accountable” person in check and uses the risk management strategies. May be able to roll up the sleeves to actually do what these above roles should do. Can take on the roles of Director, Proposition Manager, Business Analyst, Project Manager, etc.
Informed
The individual that needs to be informed of the decision and its impact.
These are the people that PMBOK calls as stakeholders that can be positively or negatively impacted by the project’s outcome. These stakeholders must be managed so that unnecessary escalation and project derailment does not happen.  The “Informed” is not limited to organizational employees and business units but customers, vendors, partners, and end-users depending upon project’s or product’s goals.

Every tool in the Project Management Book of Knowledge is so critical that it has its place in managing the project’s outcome. Understanding its purpose and utilizing it appropriately is critical to any organization’s job. RACI is an important asset to any management to eliminate waste, increase efficiency, and enhance stability.

Now, how do you foresee its use in your organization, business unit, and product or project management? Share your thoughts!

Saturday, May 31, 2014

Effective Virtual Meetings

Today's project environments face a unique challenge in holding effective meetings that contain team members physically absent due to geographic limitations spanning multiple timezones. Let us peel the layers of effective meetings.

First, it is critical to understand the cost of meetings. Meetings are one of the easiest means to erode profit margins and consume productive hours ineffectively if  used inaccurately. For instance, putting 8 people in a room for 1 hour for project status meeting would mean 8 hours or 1 productive day of a full time employee is quickly consumed. When the idea of project management evolved in the corporate world a dew decades back, more people were inexperienced working in project environments justifying the need for project meetings. But with the evolution of project management,  removal of hierarchical decision making layers with flatter organizations, sophistication of many tools in today's world question project managers calling for unnecessary meetings. This is an indication of several causes not limited to the project management inefficiency, lack of knowledge dissemination, and communication bottlenecks.

The practices of management by walking around (MBWA) has been known for a long time where key decision managers such as the project manager shouldn't be confining themselves to cubicles or office spaces but walk around to get the updates and remove the impediments faster. The agile approaches take this planning a couple of steps higher where the daily stand up meeting is used to plan for corrective actions for the coach. so, use meetings effectively and call for meetings only with members as required. Don't call for a meeting because you don't know the answer and want to show control by bringing many to the table to get the answers to avoid project derailment.

Second, now that we have addressed quickly to eliminate unnecessary meetings, let us look at distributed team members that lack non-verbal clues.  These meetings further go beyond an actionable agenda with enough time for team members to review any required information to be prepared for the meeting.  Some norms need to exist to understand time and culture boundaries.  People may take the calls from vehicles and home, irregular hours for some participants,  etc. So, muting phones unless talking, ensuring technology clashes such as not using computer microphones creating background echoes, avoiding too many parameters like conference id, password, audio key, etc besides dialing into the bridge making it difficult for people to take the call from moving vehicles, understanding constraints with the number of ports available for group meeting, and differentiating webinar versus group meetings where one person alone can talk versus many can talk at the same time are all some examples of additional meeting etiquettes.

These supplement the known order in which people introduce themselves. For instance,  people can name the next person to talk, share input, or introduce.

Third, in these meetings,  it is equally important to avoid the pretense of multitasking. While it is a good idea to request to repeat or paraphrase questions and is perfectly understandable in a multicultural team membership,  it is not an excuse for not focusing during the meeting.

Fourth, a project manager should really understand the purpose of the meeting.  An agenda is only good if we stick to it. While we don't need to go with the same order of the agenda, it is critical to ensure we don't go on a tangent moving away from the meeting's purpose.

Finally, a meeting without the meeting minutes documenting the decisions made to avoid further meetings or actions identified on who should do what by when question the productivity of such meetings. A project manager in these cases should become a good facilitator, leader,  and coach to keep the meeting in focus, document notes, and coach the team towards effective meetings.

So, meet effectively and only when required. Would you agree?

Wednesday, April 30, 2014

Key Performance Indicator must start with business need

In a recent workshop that I attended on Agile Engineering Practices, as we began discussion on differentiating the roles of individuals for acceptance test driven development (ATDD) and test driven development (TDD), question came up on what key performance indicators (KPI) are to be used. I offered my view point that the approach to deciding what key performance indicator to measure is an incorrect strategy for any organization or business unit.

Let us define what a KPI is. My interpretation of KPI is that it is an objective measure of the efficiency with which a business process is executed to deliver incremental value effectively to a business need. By this definition, I see four contributing factors in two ordered pairs, which are as follows:

  1. Business Need & Effectiveness
  2. Business Process & Efficiency

The business need differs across the organizations and within the business unit in an organization. For example, consider schedule variance (SV). This SV is a project management measure to see how the planned value (BCWP) of a project compares to the actual value for that project (BCWS).

While this SV is a very good measure of an individual progress, in regulated industries that manage portfolio or programs with multiple dependent subprojects where the control on regulatory boards are external constraints, the SV may not be an accurate measure of the performing organization’s project efficiency unless such delays are removed from consideration. So, if the goal is to measure the project health discounting such external influences, then, such measures may not accurately address the business need.

Now, when the right KPI is chosen based on what the organization’s or business unit’s goal is, we can shift the attention to the business process that is in place to address how efficiently it is serving up. For instance, if we use number of forecasted project launches to actual project launches when proper workflow, documentation, and versioning controls exist, then, the focus can become more objective to measure why tasks slipped, how projects were prioritized, etc.

As a result, whether it is a traditional software development setting or iterative software development, the focus should be on what is that we are trying to measure and why and then have the right processes and tools in place to collect data for analysis. Collecting exhaustive data accurately and apply an incorrect KPI will only lead to inaccurate assessment. Don’t you think so?

I would like to start a list of KPIs for a Project, Program, & Portfolio Management setting that would be a great list. Please let me know what you think should be added to this context.
  1. Schedule Variance and/or Schedule Performance Index
  2. Cost Variance and/or Cost Performance Index
  3. Number/Percentage of Projects Forecasted to Launched
  4. Number/Percentage of milestones missed
  5. Number of FTE hours / project in a delivery based schedule (no resource leveling)
  6. % of projects coming behind schedule
  7. Number of defects logged
  8. % of failure rate against test cases
  9. % of test cases/requirements coverage
  10. Number of Escaped Defects
  11. Burn rate
  12. % projects on budget
  13. % of Challenging Projects/Program or Portfolio
  14. % of Change Orders $ to original SOW $
  15. Internal Rate of Return
  16. Net Present Value
  17. Payback Period
  18. Net Profit Margin
  19. Capacity Utilization Rate (e.g.: Profitability per Project Management Resource)
  20. Account Growth Revenue
  21. Cash Conversion Rate (Revenue Recognition Frequency)
  22. % of Complaints over Product/Program
  23. Customer Satisfaction Index
  24. Training Efficiency

Sunday, March 30, 2014

Enhancing Productivity

Today’s corporate world is characterized by increasing pressure to deliver more but of uncompromising quality at a better rate. Increasing efficiency of production using just in time production is not new followed by build-on-demand concepts where value add to a customer takes on the focus in agile software development.  Regardless of the industry and product built, how can today’s projects still deliver increasing value maintaining the strict adherence to quality?

The fundamentals of iron-triangle of quality by managing the levers of scope, schedule and cost is still present but timelines are requested sometimes without clear scope, schedule then is accelerated to meet customer’s demands, and still cost is allowed not to increase both in operational and capital expenses. Keeping the focus to operational expenses, the question often evolves: How to measure and enhance productivity?

I believe the basics of productivity are in clarity, duration, and customer management. For projects that have somewhat known scope, such as extending a product installation in a different client site that can leverage past lessons learned, the clarity is not an issue. But, for new initiatives, the product scope may be evolving and this is where delivering to what is known using agile concepts may be beneficial.

But, the basics of duration management are differentiating the type of hours that go into the project. Productivity losses come from two types of hours that derail the project because productive time is taken out of the duration because the “right” people are not on the “right” job at the “right” time.  These types of hours are as follows.
  1. Non-Project Hours – Delivering no value to project but time for internal process enhances, functional department meetings, training, company meetings
  2. Non-Productive Hours – Time lost due to ambiguous work, lost work requests, unnecessary meetings, doing other’s work, assumption about roles, lack of accountability, etc.

The basics of project management differentiates duration from estimate in addressing the first component which is often misunderstood. Agile concepts address these by using ideal time to ensure that the story points are properly incorporating enough time to develop value. But, the second part is the difficult one that the management needs to spend additional time in ensuring that properly motivated and trained people are present, tools are sufficient, and collaboration is cohesive.

In terms of the customer management (remember client is both internal and external), the productivity goal should be to maximize hours charged to a project, establish a baseline for products of similar nature and use appropriate time entry/approval methods to evaluate against the baseline, forecast and promote predictability of workload and hold everyone accountable. The principles of stakeholder management are no wonder a newly added separate dimension in the Project Management Book of Knowledge.

In summary, productivity measure are rooted in people, process, and tools that allow the job to be defined in adequate detail, breakdown accountability by increasing collocation, introduce distribution tools for effective collaboration, lead instead of manage the clients more effectively, and use process as a key vehicle to integrate the whole in a virtual distributed environment.


Thoughts? 

Friday, February 28, 2014

Ingredients of a Transformational Leader-What can you do?

Leadership is one of the frequently talked about topic in scholarly and professional literature and yet is the most confused topic. From the great man theories promoted Dowd (1936) emphasizing different degrees of intelligence, energy, and moral force in leadership and contingency theory focusing on task or relationship orientation in effective leadership (Fiedler, 1967) evolved the integrative people-value based theories of transformational leadership evolving from theory and servant leadership evolving from practice have found their common place in many organizations.

Yet, the leadership component is evaluated on management that focuses on tactical execution. Some of the reactive nature of business units makes executive management evaluate if these functional leaders are proactive and transformational. Questions evolve on proactive processes put in place to control chaos where efficiency of management is confused with leadership of effectiveness. In a dynamic demanding organizational environment, what are some of the ways for transformational thinking?

Burns (1978) began with the idea of transformational leadership that Bass (1990) expanded. Additionally, readers are directed Scholar-Practitioners like Peter Drucker and John Kotter for leadership and management. But, here I would like to present a few questions and tips that will map to the four “I”s of Transformational Leadership so that one can walk away with actionable steps. Transformational leadership exhibit idealistic influence by inspiring and motivating the team, giving individual consideration differentiating from group and team, and intellectually stimulating them to excel themselves. How could this be done? 

Given below are five questions that people can ask them to
1      How do I facilitate getting the job done always?
2       Do you feel like you have a role or a job?
3.       What have you done to make a member exceed their abilities and grow their skills?
4.       What makes others reach out to you?
5.       What do you know of the individual’s career goals?

Transformational Leadership Category
Some Thoughts – Actionable steps
Ideal Influence
1. Walk the talk and avoid lip service. Let the results speak to your efforts.
2. Build trust for the team by “being there” for them and modifying people’s behavior to embrace change
3. Proactively implement new ways to organizational culture
Inspirational Motivation

1. Learn what motivates people – extrinsic and intrinsic needs.
2. Learn from failure so that future strategies can avoid risk and improve quality
3. Maximize learning from success so that these are not accidental outcomes but repeatable outcomes
4. Ask how you contribute to the organizational vision and empower them for change.
Individual Considerations

1. Give work assignments to match one’s skills but challenge you to grow them by pushing them out of comfort zone. Be a servant leader – they may not how it benefits them always.
2. Consciously build a career plan. You owe it to your team even in a balanced matrix organization by providing recommendations.
Intellectual Stimulation

1. Foster Creativity & Innovation - If the wheel is not broken, then, you haven't looked hard enough.
2. If people agree too often with you, ask yourself if you are surrounded by "yes" men.

Henry Ford once said, “Coming together is beginning; keeping together is progress; working together is success.”  To me success is a meeting point between preparation and opportunity. We need to prepare ourselves to lead before an opportunity presents itself. Understanding one’s own drive and emotions is instrumental to understand the others, which is a perquisite for the transformational leadership that is practiced every day with effective habits on us first before they can be practiced on others.

Are there any other actionable steps or questions that can make this list more comprehensive for practice?

Friday, January 31, 2014

Need for Statistics for Project Managers

“I am not good at statistics. So, I am not cut out to be a project manager,” said a potential PMP aspirant after attending a PMP boot camp. My heart slipped a few beats to regain my stand and found out from this potential PMP candidate managing dates in the timeline, evaluating project slips, looking at contracts for vendor management, and monitoring metrics demand high mathematical skills for a project manager to be successful.

Let us look at the core knowledge areas in Project Management Book of Knowledge that includes management of scope, time, cost, risk, quality, communication, procurement, integration, human resources, and stake holders. Most of the process groups within each one of these domain knowledge areas involve qualitative thinking, leadership, organization, negotiation, and people management skills. For instance, the project manager that asks for what percentage of a task is completed draws attention in today’s context because even if 80% of the task is completed, the remaining 20% of the task can take more time to complete. Understanding people’s commitments and winning consensus towards project goals is central to task completion, and therefore eventually project success.

Even when we focus on metrics, such as cost or schedule variance, schedule or cost performance index, or other earned value metrics like planned value and actual value, estimate at completion, etc., the mathematical formulas involve simple subtraction and proportions. Do these mean they are statistics? How much difficulty exists in comparing the milestone slips from baseline to actual? Simple office automation tools like Microsoft Excel can accomplish these computations effectively and if the proper use of Microsoft Project is used, then, these metrics can be easily computed.

Now, let us turn our attention to Agile. Technically, project plans are not preferred in this setting as the teams are dedicated and self-managed. The project manager is not managing the tasks. Focus shifts more towards product features, benefits to business, etc. Neither the estimate gathering process like planning poker or metric computation like velocity planning is quantitative. Besides, good application lifecycle management (ALM) tools like SpiraTeam, Version One, or Rally allow such metric gathering more effectively. So, where is statistics coming in to play as a core skill of a project manager?

Let us not leave capital project selection where the management using steering or governing committee must make a conscious selection of products to invest or consume resources to work on. These ranking of projects use basic mathematical concepts like payback period, net present value, or internal rate of return. None of these methods call for detailed analysis of variance, kurtosis, skewness, or involve factor analysis.

Besides, if simple observations of ratio and proportion or central tendency analysis using mean, mode, or median mean statistical expertise, then, how much time are a Project Manager spending on such analysis compared to communicating and managing stakeholder expectations to ensure project success?
So, is statistics a core skill for PMP aspirant? Readers, what do you think?