Risk Managemeent: Key to Advancing into Program Management

The Project Management Institute (PMI) introduced the principles behind program management with a critical focus on maximizing benefits.  Often project management focuses on controlling scope and schedule using available workflow tools that they miss an important component of not understanding the value of the project on a larger scale.

The question to ask here is what role did the project play in increasing the value to the performing organization, customer, and the society?  When we think about this and focus on the benefits, we step into the next stage of ensuring the project risk is constantly monitored.  There are various tools to managing risk but constantly keeping focus and most importantly the risk register.

Understanding these risks is a critical element to the next stage called program management.  Why? This is because the program management focuses on what an individual project can't deliver. The impact on value maximization is high in program management. If the risk is not more actively monitored, there will be too many interproject dependencies that may impact these projects more. So, when advancing to program management, active risk management is critical and is a sine qua non for project management excellence.

Furthermore, risk management is at the epicenter of value management. While project management focuses on delivering products, services, or results, program management focuses on benefits delivery. Since the extent to which businesses and customers derive the benefits describes value, in delivering products or benefits, lean principles advocate flow by avoiding delays. As the day passes, value should be incrementally built. Even when the project may not have been launched and the anticipated benefits realized, we monitor the progression of work so that projects don’t slip, tasks don’t wait, or decisions are not delayed. From the discipline of earned value management, this is why we even look at the 'value' earned in a snapshot in time!

One thing that I was very proud of in my current workplace is that there was an all-hands meeting from all account managers, project managers, development representatives, script writers, creative artists, testing team, and operational team members. The project management team was responsible for holding this meeting on a weekly basis at a predetermined time on Tuesday with remote representatives and traveling account managers on the telephone bridge. This meeting served as the 'synchronization' meeting where everyone synched on raising their part of the risks and issues as well as the impact to the project, client, and the revenue to be recognized by the company! Everyone was willing to pivot accordingly because there is only limited capacity of time/resources available! 

Now, will synchronization alone contribute to seamless value flow? Let us see. While each team had their independent meetings to discuss what was in their backlog. The creative team had a weekly meeting to discuss department specific projects and client specific projects. The development team had its daily standup with the onshore and offsite engineers. The account management team had their own retreats (that's the name they used) to discuss client and deal with specific issues. So, each team had its own cadence on when to meet, what to discuss, etc. 

Therefore, although both cadence and synchronization were present, some of the challenges that we repeatedly discussed in the synchronization meeting emphasized that there were other forces at play impeding value flow. The most common things that came up are the following:

• Lack of Visibility: There was no combined backlog or a visible backlog of what happened inside every team. If a team discussed a new project that is slowing work for other initiatives, that was a surprise!
• Multitasking: Some teams had a single person working on multiple things. For example, a creative artist was assigned to more than project extending the amount of time taken for both projects. This diffused the need for more resources required to meet the increasing demand. Delays in projects slowed value delivery and revenue recognition. 
• Size of the Work Commitments: Some work commitments made were large. There was not enough questioning of the estimates to the commitments made. Sometimes, there was only one single person available to do such work introducing the key candidate risk. 
• Complicated Workflow: Some review and approval steps in the process were unnecessary, increasing the amount of time taken for people to wait on those steps. The time zone and the manual processes fueled this fire further. 

I believe value is proportional to the waste reduced (value = f (waste reduced)). Some of these value blocking forces causing waste are common in many companies. We tried to address it by having cross-functional representatives in other cadence meetings, consolidating tools on a single ALM tool, introducing role-plays with team members rotating with others, and reviewing steps in the workflow to minimally required to ensure compliance. What other techniques could have worked? Please share.

RACI: Errors and Implications in building the right one

Earlier in the blog, we had discussed an overview of RACI. It is a great tool in every project and is an important tool in the Portfolio, Product, Program, Project, and Process Management Office (I call this P5MO). Too often, however, not knowing how to use this tool is like having a wrench used when a screwdriver 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 people  involved, then the task is adequately defined leaving ambiguity in the task. As a result, many people are required to perform. Now, agile teams 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 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+ Rs for a task, then, trouble is brewing!
2	Too many A’s	This is the person that is answerable to the management and resolves  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” members 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 the 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 for it. Then, this is something that the project manager must identify in the risk register and follow through to get a closure.
4	No A’s	This is the opposite extreme of an earlier problem with much severe risk exposure. There is no accountability for any work done, leaving 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 with 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 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 is 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 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 several 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 nor 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” members 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? 

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 the 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 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 reason for requiring a RACI becomes essential when the organization is siloed 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 manage 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.  In the Power-Interest grid, the R members are mapped to the "Keep Informed" (Low Power, High interest) quadrant for the most part.
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 the risk register effectively by mapping the risk owner to the RACI. In the Power-Interest grid, the A members are mapped to the "Manage Closely" (High Power, High interest) quadrant for the most part.
Consulted	The individual required to offer input and contribute to the activity.	This person offers 2-way communication and is a domain expert. This person should hold both “Responsible” and “Accountable” person in check if only they consult. This person alternative risk management techniques like the root cause analysis, force field analysist, and SWIFT (Structured What If Thinking) promoting thoughts that may otherwise be missed impeding flow. May be able to roll up the sleeves to do what these above roles should do. Can take on the roles of Director, Proposition Manager, Business Architect, Project Manager, etc. In the Power-Interest grid, the C members are mapped to the "Keep Satisfied" (High Power, Low interest) quadrant for the most part. But they could also come from any other quadrant.
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 projects or product’s goals. In the Power-Interest grid, the C members are mapped to the "Monitor Marginally" (Low Power, Low interest) quadrant for the most part. But they could also come from any other quadrant.

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!

References

Project Management Institute (2013). Project Management Book of Knowledge. Fifth Edition. New Town Square, PA: Project Management Institute.

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 exhibits 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 some 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?

6.    How have you addressed “what’s in it for them?”

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?

References

Bass, B. (1990). Bass & Stogdill's handbook of leadership. New York: Tl1 e Free Press.

Bums, J. (1978). Leadership. New York: Harper & Row

Dowd, J. (1936). Control in human societies. New York: Appleton-Century.

Fiedler, F. (1967). A theory of leadership effectiveness. New York: McGraw Hill.

Chaos Control: Agility in transforming communication - SIT principle

One of the main ingredients of a Project Manager’s success is taking charge of communication. If communication is half of the struggle, then, how you communicate is the remaining part of the trouble. Recently, I observed a series of emails from several remotely distributed team members. Within a few hours, there were close to 35 emails on the same topic with various members not always picking up the latest thread and using that prohibited button, “Reply to All”. Reminding me of a war room where all members were screaming at each other, this observation is an example of “Email Noise” that serves its very opposite purpose of “Clear Communication.” Proving that emails lose transparency to project team (let alone executives), fails to hold people accountable in a situation that calls for collaboration, and loses control in prioritizing the work queue unless the project manages “takes charge”.

Agile principles promote that teams should be collocated for this reason. Besides, communication is structured to ask what happened yesterday, what is going to happen today, and what are the obstacles to reaching the goals? While change is constant and agile accommodates it, this does not mean that some basic principles of productivity management for systems development (Barry & Wyatt, 1996) should fly out the window. These principles include 1) defining the job in detail, 2) getting the right people involved, 3) estimating time and costs, 4) breaking the job down, 5) establishing the change procedure, and 6) agreeing on the acceptance criteria.

Remote distributed virtual team structures are not disappearing. Project Managers and functional leaders should become attuned to this requirement and need to be “agile” in their thinking and communication so that these team structures can still benefit from unambiguous communication that I believe can be categorized into one of the three categories – Semantics, Influence, & Technology (SIT). 

1. When the question is relatively easy (Boolean response of somewhat fuzzy but still not complex), it can be categorized as technical. For instance, checking on availability of an individual to cover for someone during a holiday period (Boolean) or requesting someone to check for review error logs to identify the cause or review a long document for clarity, resorting to email is better.
2. But, when the same requires deeper discussions requiring prioritization of tasks to meet client needs, and working on multiple projects that have resource constraints, then, communication is no longer simple requiring one to exhibit influence over what the project team may think.
3. When the team structure is distributed across time zones or the environment requires navigating through multiple client priorities, personality profiles, escaped defects noted by the client in production aggravating users, the communication evolves to semantics where ambiguity reigns.

One may find that this resonates to the principle of information theory where the Channel Capacity (C) the strength of “signal” must be increased within the allowable limits of the bandwidth in the channel (B) over the noise (N) introduced. Interested readers can review the Shannon-Hartley theorem (n.d.) for the details. The same is true even in Project Communication:

Clarity in communication is directly proportional to the versatility of the communication style of the originator and inversely proportional to the presence of verbal communication in the communication medium. 

I view this clarity in communication as the utility value of the agility in communication. An email going out asking a question or answering a question for which another question is asked in response means that communication is ambiguous. Such iterative sprints of email communication will not be interactive yielding results when influence and semantics mandate attention. Use of video podcasts, conference bridges, and plain collaborative conversations will transform the signal strength in communication. Using this SIT model, determining the right vehicle to communicate is more important than communication. To be successful in agile, one must be agile and think agile. Results will then speak for themselves.

References

Barry, T., & Wyatt, B. (1996). The six principles of productivity management - project management for systems development. 27^th Annual Seminar/Symposium, Project Management Institute.

Shannon-Hartley theorem (n.d.). Retrieved Aug 27, 2013, from http://en.wikipedia.org/wiki/Shannon%E2%80%93Hartley_theorem

Importance of Domain Knowledge for Project Manager Excellence

So, what is necessary for a PM to excel or prepare for career change? Look at the various job requirements for project managers. Can you see a job posting for a Healthcare Software Developer post, a Retail Database Administrator, or a Financial Services QA analyst? No.

But you can see job posts asking for specialized experience in the application or technical domain areas knowledge. See examples such as the recent job requirements - a Java Programmer, a SQL Server Administrator, or a SAP Quality Engineer - that have surfaced recently.

Similarly, several jobs in project management have begun asking for industry specific domain knowledge. The postings like a Healthcare Project Manager, Pharmaceutical Project Manager with IT experience, IT Project Manager, Infrastructure Project Manager, Construction Project Manager, etc. speak for the increasing attention to specific domain knowledge skills that team members and stakeholders are seeking in a project manager. 

But how prepared are the project managers in specific domain knowledge areas? Let us be clear. I am not talking about technology skills, such as understanding programming or IP address configuration. And shouldn’t an IT Project Manager understand to differentiate whether an IP address is internal or external facing? Before answering that question, think if NASA can hire a project manager who doesn’t understand the various contracting requirements to work with federal agencies and contractors?  

A recent job requirements for a project manager asked for knowledge of image processing and remote sensing requirements. Requirements for another chemical project manager asked for chemical manufacturing process and drafting requirements. What are the signals from the market then?

Specifically in the growing agile projects where projects are not fully defined, isn’t having this domain knowledge helpful to identify risks early, facilitate negotiating for what stories are going to add value to the customer, and establish trust in a self-organized team?

Considering these market conditions, are the accidental project managers or the graduates with a focus on project management adequately prepared to manage projects or for career change? The T-shaped skills are a must with a breadth of knowledge in multiple areas and depth of knowledge in the chosen field.  Although I talk about these cross-functional domain knowledge for project managers, I think the discussion equally applies for people in technical field. For instance, it is important for developers, testers, and creative artists to know principles of project management, risk management, and agile approaches. 

What do you think?

Will tools make up for an effective Project Manager?

Give a problem statement to two programmers of similar skills and there may not be a complete overlap of their solution.  With so many books on programming, one may think programming will be an exact science, but programmers will claim that it is an art.

Project management is not any different.  The accidental project manager may have come to the profession either due to their excellence in their chosen field or just landed up due to networking connections. Regardless of how they entered the field, they will have to understand the core set of skills.

Project Management Book of Knowledge goes into a lot of techniques, such as activity sequencing, contract types, change control, etc. One must understand that these are guidelines and operating framework.  Tools such as Microsoft Project and Microsoft SharePoint have addressed a number of these requirements in their software to do resource leveling, critical path analysis, multi-project dependency, document sharing, team collaboration, etc.

The market conditions are changing. As adaptive approaches become more popular with teams committing to work done and breaking the stories (deliverables) themselves into tasks (activities), are project managers required to compute critical path or incorporate task level dependencies? If we continue to do these things ourselves, how much are we enabling the teams to self-organize and take decisions themselves? From an organization standpoint, how are we able to tell the bigger picture of how we are allocating capacity and where we are seeing risks? In other words, where is the single source of truth? Newer tools are emerging, and we need to be able to demonstrate our willingness to unlearn our tool affections and relearn what our customers need and the industries demand!

So the tools don't build credibility for project managers. Think of a project manager that updated the tasks in the Project Plan but failed to provide unambiguous direction to the team or failed to elevate to the management the increasing scope of a client? Will tools address these issues? How are the risks factored into how we prioritized our work in the WBS?

Just like knowing SQL Enterprise Manager doesn’t make one write excellent stored procedures or queries or Visual Studio/Eclipse does not make one write flawless code, basic understanding of MS Project or SharePoint alone will not make an effective project manager. Expertise in these tools is a necessary requirement for a project manager but not sufficient for leading successful project outcomes.

New Breed of Project Managers

In a parent-teacher meeting, a question came up on what my son wanted to be when he grew up. When he expressed his dream of becoming an IT Project Manager, the teacher appeared clueless. Perhaps, a doctor or a lawyer or computer engineer would have satisfied the teacher. That left me wondering why there is no recognition of the role of project managers despite the growing demands to successfully deliver various types of projects.

Fundamentally, the role of project management is still not perceived to be effective and can be grouped into individual’s lack of passion to the field, management’s myopic vision in preparing individuals, and lack of job expectations of project managers.

If a .Net programmer must know basics of programming and exception handling, data or data administrator understand the details of SQL, member of the financial management team understand the differences between balance sheet and cash flow statements, construction engineer understand the codes expected to ensure safety of work in the construction site, what are the expectations of a project manager? Project Management Institute proposes minimum of general business skills, application area skills, and project management skills and if those that do well as a customer service representative, lead team developer, QA team lead, or account personnel are asked to take on managing projects, how many are exposed to the project management domain areas of risk identification, critical path requirements, team motivation strategies, etc.?

Either the management retains the responsibility to properly train such career growth initiatives with adequate training or the individuals exhibit passion to learn the pulse of the profession. Downgrading their expertise to learning Office Suite of products to help them do basic what if scenarios in Microsoft Excel develop charter or provide status or communication reports using Microsoft Word and and do simple task management using Microsoft Project seem to have developed the task oriented accidental project managers. The net impact is the profession lacks the credibility that is attached to the profession.

This perception must be managed, and project managers must become attuned to the industry and application domain knowledge, organize their project using proactively managing the tasks and establishing clear roles, understand the need to negotiate with stakeholders and team to provide the optimum business value with minimally marketable features, and resonate with the individuals energizing and empowering the team to success.  Strategic project managers that come to or stay in the profession by choice will enrich the field of project management.