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.

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 time zones. 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 a 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 few 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) have 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 standup 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 as 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. Wouldn't you agree?

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 viewpoint 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 (Objectives and Key Results [OKR] comes here)
2. Business Process & Engagement (Critical Success Factors [CSF] comes here)
3. Delivery and Operational Efficiency (Key Performance Indicators [KPI] comes here)

The OKR is a corporate level initiative that connects with the vision ("As is" to the "To be" state based on BHAG ideas). This may emerge from the portfolio function (identified in the business case) requiring what needs to be done across the organization (identified in the project/program charter) to align stakeholders, commit resources, and engage for success (that I call as ACE for charter). Consequently, each business unit comes up with its own critical success factors (CSF). In my opinion, the CSF is spread in at least 6 areas (Strategy, operations, product, marketing, finance, and people). Now, as programs and projects are chartered to deliver benefits through capabilities, enablers, and features in the product portfolio, the KPI measures the delivery and operational efficiency.  

If we conceptualize all these areas together, then the overlap between each domain (OKR & CSF, OKR & KPI, CSF & KPI) is the Key Result Areas (KRA) that all business units collaborate vertically and horizontally (this is where value comes). Every interaction is loaded with several external and internal risks and so are associated with the risk assessment. This is one of the reasons why products, projects, programs, and portfolio have risk (as measured by Key Result Indicators) as the central vehicle throughout the organizations (OKR & CSF & KPI & KRA).  Without understanding these interconnections, if we drive to use KPIs, then these are anti-KPI patterns because we are not measuring what matters!

 Dr. Rajagopalan's Conceptualization of the relationship among OKR, CSF, KPI, KRA, and KRI

Business needs differ 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 projects successfully launched 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 applying an incorrect KPI will only lead to inaccurate assessment. For instance, measuring defects logged by tester would motivate the tester to log too many defects instead of consolidating them in one (like grammar, spelling, punctuation, formatting on a single line logged as multiple bugs). Everything countable does not always count, right! 

I would like to start a list of KPIs for a Project, Program, & Portfolio Management setting. This would be a great starter list. Please let me know what else should be added.

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 reached/missed by project
5. Number of FTE hours / project in a delivery-based schedule (no resource leveling)
6. % of projects coming behind schedule
7. Defect Density (Number of defects logged against requirements)
8. % of failure rate against test cases
9. % of test cases/requirements coverage
10. Number of risks against requirements/test cases
11. Prioritization of requirements/test cases based on risks
12. Task Progress (against DoD)
13. Extent of ATDD/BDD by Business Users (e.g.: exploratory tests)
14. Number of Escaped Defects
15. DORA metrics
16. Cycle Time, Lead Time, WIP
17. Estimation Accuracy
18. Commitment Evaluation (e.g.: Planned vs Actual Velocity)
19. Backlog Growth and Burn rate
20. Risk Reduction Rate (Identified, Treated by Response Type, Residual)
21. % projects on budget
22. % of Challenging Projects/Program or Portfolio
23. % of Change Orders $ to original SOW $
24. Internal Rate of Return
25. Net Present Value
26. Payback Period
27. Net Profit Margin
28. Capacity Utilization Rate (e.g.: Profitability per Project Management Resource)
29. Account Growth Revenue
30. Cash Conversion Rate (Revenue Recognition Frequency)
31. Concept to Cash Cycle Time
32. Marketing Metrics 
33. % of Complaints over Product/Program
34. Customer Satisfaction Index (e.g.: NPS)
35. Training Efficiency

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 on 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 differentiate 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 (2013).

In summary, productivity measure is 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 managing the clients more effectively, and use process as a key vehicle to integrate the whole in a virtual distributed environment.

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.

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 are 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 indicate 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? It is true that interpreting such data for preventive and corrective actions as well as escalating risks and issues require some understanding of these thoughts. So, is statistics a core skill for PMP aspirants? Readers, what do you think?

Essential Leadership behaviors for Agile Transformation

In the recent Scrum Coaches Retreat that I attended, I saw a pattern where the majority of the topics presented for discussion centered on organizational transformation and implementing agile correctly. The topics ranged from change management traits for individuals and organizations, executive leadership behaviors, coaching approaches for executive leadership, coaching for non-technology groups to implement agile, facilitation techniques for team trust, and scaling agile for coaching within an organization. Having established, led, and managed a program management office (PMO) in a healthcare IT and professional services industry and with a strong desire on leadership behaviors through project management and product development, I joined the team on this theme seeing an increasing focus around executive leadership behaviors for leading organizations to embrace agile successfully (“Build an Agile Organization Executive Coaching”, 2013).

Following the agile principles of user story development, our group with backgrounds from multiple industries began identifying the major categories of persona in today’s leadership that lacked understanding or came with a traditional mindset in transformation. These observations were later shared across the various participants from numerous countries during our daily retrospectives to further refine our persona categories. The major themes of persona classification of executives evolved are listed as follows that I have reordered in a continuous spectrum of the knowledge of agile in their implementation challenges.

Resistant: The executives that fall into this category are those that have a generational gap leading to a resistance in change. The relevance to current ways of managing projects or understanding product development is not in the radar screen for taking the organization to the next level. These leaders are more task-oriented managers than leaders who feel challenged that agile may not add value. “It has been working for me and so I see no need for agile” is the theme behind such leadership.

Never heard of agile: The executives that fall into this category are open to ideas but are unfamiliar with the agile framework.  This group’s lack of understanding may arise due to many reasons such as their own personality towards new learning, lack of initiative, and firm’s industry representation to understand new trends. These members often rely on the experience of others bringing in consultant experience or another senior member to implement the transformation. If the consultant or the senior members fail to apprise of the executives of the implementation challenges in product development, skills reorientation, and the structure required for agile development to thrive, then, these executives lose faith in Agile.

  

Big Vision: These groups of executives understand that their current structure is not in line with their big vision for growth. They recognize that they need to develop products differently for competitive position of themselves in the marketplace or excelling in doing things efficiently. They have heard of the agile framework through their own due diligence to implement their growth ideas and look forward to their delegates for support.

Misinformed: Similar to object oriented programming where the subclass inherit characteristics of super class, this group of executives have had bad experience from the earlier bad implementation in their organization or in a different organization. Their “bad taste” of agile implementation shouldn’t be attributed to agile framework’s failure but the failure of those leaders or consultants that didn’t implement a stable and scalable solution.

Metric Oriented: Some executives have an instinct to not just focus on the profit motive but also establish key performance indicators. But lack of having correct types of metrics and threshold to begin with may impede successful implementation.

Insufficient Experience: This final group leans on those consultants or senior members that are brought into the organization just because they have implemented agile in their previous job. As Boyatzis and McKee (2005) noted, these high-profile members need to understand the emotional makeup of the new organization and not just their own personal success in their previous job. The reliance on a structure or set of tools that they had found useful previously but failure to understand the new organizational structure, impediments, and product makeup among others add up to the challenge of insufficient experience that these roles bring to implement agile transformation successfully.

In the end, the successful implementation relies on proper coaching of the organizational executive for leadership behaviors that they need to inculcate to succeed leading to forming a team that can coach and train the organization. If the leadership has not bought into the fundamental twelve agile principles for successful agile transformation and middle management members like functional team leads and project management not trained on product ownership, project team leadership, process governance, and client management, then, the fragile leadership should be held accountable for agile framework’s failure.

Do you think there may be other persona besides these persona classifications?

References

Build an Agile organization executive coaching (2013). Scrum Coaches Retreat. Retrieved December 17, 2013, from http://www.youtube.com/watch?v=4z_6rEkTP8k&feature=youtu.be

Boyatzis, R.E. & McKee, A. (2005). Resonant leadership: Renewing yourself and Connecting with Others Through Mindfulness, Hope, and Compassion. Boston, MA: Harvard Business School Publishing.

Execution as a Strategy in Acquisition – Relevance to Agile Transformation

In one of the networking events on effective agile transformation that I facilitated, one of the learners asked a question about how agile did not measure well in an organization that the learner’s organization acquired. The learner reasoned that the acquired company was a smaller organization that claimed financial profit in a niche market but has been bleeding after acquisition when adopting agile. While the specifics of the details have to be left out in this blog, the discussion made me realize some of the pitfalls in agile adoption in mergers & acquisition prior to shifting responsibility of failure on agile practices.

This quest for executing mergers & acquisitions (M&A) successfully led me to pursue several articles and books which made me feel that “Execution” itself should be “strategically” thought through by leaders within an organization and particularly with M&A.  Paul Burmeister, who has executed in the capacity of COO and CFO in many industries, quotes multiple ideas to ensure that the M&A activity becomes successful, emphasizing critical importance of the leaders’ synergy from both the organizations to establish success factors to measure the efficiency of integration.

Among these stands out an important point on whether the M&A focuses on products, processes, and intellectual capital (Dahl, 2012). While M&A accelerates the acquiring organization’s competitive advantage by leveraging the new product line or the intellectual capital that leads to quicker access to additional markets horizontally or vertically, the reference to processes differentiated how clash of various processes (waterfall versus agile) may have to carefully weighed.

I think here is where organizational leaders may be failing to adopt asking “what would have to be true for the” execution to continue to be a fantastic choice? (Lafley & Martin, 2013, p. 204) If leaders failed to understand the twelve principles behind agile and scale them appropriately, then, they have created an organizational impediment for agile to fail their organizational success. Rationalizing on how the acquired company has always functioned differently and seeing no need to change fails to take advantage of the additional capabilities that come with the acquisition, reasons Jeff Sutherland, one of the contributors to the Agile Manifesto, who attributed the organization’s failure to remove impediments for Agile to fail (Larman & Vodde, 2011).

Once we come to terms that we have to review the processes in place, there are a couple of additional areas to look at for successful integration of agile in M&A. These include identification of proper product owners and tools for interaction. Unleashing properly spaced-out adoption of skilled people to work as product owners that understand the agile principles of establishing a good risk adjusted product and sprint backlog, prioritizing the backlog to build trust and maintaining a cadence balancing team’s commitment in distributed and virtual teams that have to be embraced, and recalibrating on the tools of communication is vital. Charlie Rudd, CEO of SolutionsIQ, underscores how organizations fail to implement agile without building the product owner capability (2013, para 5). Firms should give importance to training in such a way that time is made for people to get trained, says Larman & Vodde (2011, para 4).            

Given these observations, what other execution specific strategies should one consider for agile to succeed with M&A activities? Should there be a standardized M&A integration checklist put together for agile success and if so, what are some pointers to definitely consider? Please share your thoughts.

References

Dahl, D. (2012). 7 steps to a successful company merger or acquisition. Retrieved Oct 10, 2013, from, https://www.openforum.com/articles/7-steps-to-a-successful-ma-a-small-business-guide/

Larman, C. & Vodde, B. (2011, February 9). Top ten organizational impediments. Retrieved Oct 11, 2013, from http://scrumedge.blogspot.com/2011/02/top-ten-organizational-impediments.html

Value of Product Governance & Portfolio Management in Agile Product Development

In a networking event on effective agile transformation, a question came up from a few learners in terms of the practices of project governance in capital project selection was agile or traditional development practice. The same question manifested differently in a PMI-ACP class I was facilitating where a learner expressed the challenges with not doing some proactive requirements gathering exercise around the extent of data exchange methods from the application service provider as part of the Agile approach to favor customer collaboration over contract negotiation. The learner reasoned that the later negotiations to add these requirements only hurt the organization with increased costs, reduced speed to market, and decreased customer satisfaction and organizational profitability.

There seems to be a common pattern that I think is evolving where practitioners of agile are forgetting the importance of Agile Manifesto. While Agile Manifesto was prohibiting extensive upfront requirements gathering for software product development keeping working software as a measure of progress, the Agile manifesto never eliminated documentation requirements. In fact, the stage-gate approaches promoted by Dr. Robert Cooper from the Product Development Institute (Cohn, 2010) takes product development from discover to post-launch review through the stage gates of idea development, business case development, development, testing, validation, and launch introduces multiple stage gates. Each stage gate becomes a major milestone serving as a go/no-go decision-making point.

A formal product selection criterion, also advanced by Project Management Institute’s Program and Portfolio Management Processes, for the organization to evaluate the key performance indicators to measure the return on investment (ROI) and use financial measures likes Internal Rate of Return (IRR), Net Present Value (NPV), & payback period to evaluate the profit potential, operating expenses, resource requirements is not prohibited by Agile Manifesto. Some product development where specialized expertise is outsourced to be competitive in the market, dependencies on external vendors that handle testing or audit procedures, use of distributed agile teams, or adherence to high quality management practices like CMMI may mandate that the standard operating procedure (SOP) is clearly outlined so that the teams productively work towards product development and are not burning unnecessary cycle times with delays and external dependencies. Not considering these things in advance by using Agile Manifesto as the shield to avoid “Contract Negotiation” or “Comprehensive Documentation” is not the failure of Agile.

Mike Cohn (2010), a pioneering contributor to the Agile Manifesto, recommends that any document or artifact required to achieve compliance be part of the product backlog and use of agile project management tool and practices for products in the regulated industries demanding compliance requirements. In a white paper submitted by Primavera, Oracle (2011) recommends the combination of Agile and Enterprise Project Portfolio Management (PPM) systems mitigates the risk in pharmaceutical and financial services industry (p. 3) increasing visibility of projects, resources, schedules and business value for the entire organization (p. 6).

It is therefore evident that our own understanding of Agile framework’s core principles may have to evolve when we apply agile in different industries. But, putting down project governance, product selection, and product portfolio management techniques as ineffective practices promoted by Agile is choosing to ignore the best practices. It is no wonder that topics of scaling agile are evolving leading to the latest description of Scaled Agile Framework (2013) for implementing scaled lean and hybrid agile framework in enterprises.

References

Cohn, M. (2010). Succeeding with Agile: Software development with Scrum. Boston, MA: Addison Wesley

Description of the Scaled Agile Framework (2013). Retrieved October 26, 2013, from http://scaledagileframework.com/purpose/

Oracle (2011). The Yin and Yang of Enterprise Project Portfolio Management and Agile Software Development: Combining Creativity and Governance. Retrieved October 27, 2013, from http://www.oracle.com/us/products/applications/primavera/primavera-eppm-agile-wp-453028.pdf

PMO Agility: Business case to operate as a Profit center

In a recent networking event that I hosted on Effective Agile Transformation, a question came up from interested attendees on whether a Project Management Office or Program Management Office (PMO) should have different metrics to measure projects. An example of a metric that was tossed around was that projects in a traditional waterfall approach may use schedule variance whereas agile projects may measure velocity.

I believe these questions are rooted in traditional thinking where people look up to Agile as a radical way of doing projects differently only to arrive at the same results. Stacey’s diagram that Agile principles promote call out that not all projects will benefit from applying agile principles of iterative and incremental delivery. So, all types of projects should be evaluated based on value generation. Any type of key performance indicator basically evaluates this value generation as evidenced by Michael Porter’s value chain theory where project management is an indispensable support management activity.

First, PMO (sometimes called Value Management Office, Value Delivery Office, Centers of Excellence), is a portfolio function (which means there is no end date, and any project/program may or may not be related). The goal of the PMO is a governance function rather than management function. The PMO should continuously review seismic changes in the market and its impact on the organization (external influences) and plan to build capability and capacity. So, PMO functions are not just metrics driven. In my opinion, PMO is responsible for the following so that the organization's strategy and goals are supported sometimes by allowing to take on projects never taken by the organization before laying the foundations of profit center.

1. 3C: Capability, Capacity, Change Planning (e.g., EEF/OPA support)
2. 3R: Resources, Risks, Reporting
3. Knowledge Management is supported by focusing on both 3Cs and 3Rs through ongoing training and evaluation.

As some organizations are in the emerging stages with five different levels (like supportive, controlling, directive, mature, and optimizing), it is possible that the PMO focus takes on some levels of measures of performance and metrics to monitor these measures.  From that angle, let us explore profit center thoughts from a measure's perspective. 

For instance, let us consider “Time to market.” This metric measures the elapsed time from the onset of the project to its delivery. Measured from the start date to the end date in the baseline may go for, say 8 weeks. Now, an experienced project manager may use the “80-hour” productivity rule to mark a milestone introducing checkpoints for incremental value delivery. This milestone may be a requirement freeze, delivery of a certain development, receipt of assets from a client, procurement of a vendor contract, etc.  This 80-hour commitment is already making a project manager think agile in a project that need not lend itself for agile implementation. Unlike an agile project, this 80-hour duration need not be equated to a certain number of story points to establish a team velocity.

Therefore, while every PMO needs to be formed based on business needs and not all metrics may be equally extended to all PMOs, I believe and challenge all business driven PMOs to think and act like Profit Centers instead of cost centers while measuring value generation. This value generation underscores project managers to become skilled at proactively managing the projects by becoming subject matter experts in the domain skills relevant to the project, master organizational skills to mitigate risks, learn negotiation skills to control the project scope but allowing changes, and understand empowerment skills in energizing and motivating the team.

As an example, let us take the “Time to market.” Let us say, if two similar projects that focus on developing a website are developed by two different project managers. Now, if on a consistent basis one project manager can deliver projects of similar complexity in 6 weeks while the other project manager takes 8 weeks to deliver, then, the skilled project manager has shown the organization that the cost savings for 2 weeks on a consistent basis from the agreed project baseline duration of 8 weeks. If PMOs operate as profit centers, then, the PMO can look for increasing the skills of the PM in project management areas to think and be agile. 

What are your thoughts?

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

Agile Success Seed: Product Owner’s role to manage risk

One of the common themes that often percolate as organizations transition to agile approaches has been the identification of who owns the product vision. In a traditional project, often as recommended by Project Management Institute, effective project managers control the risk related processes as they own the project's scope. With agile thinking, this burden of responsibility shifts to the product owner because maintaining the product roadmap (starting with the vision) and grooming the product backlog is the product owner’s responsibility.

But one of the common pitfalls that I believe is a root cause for agile project's implementation failure is the inadequate orientation of the product owner to be available to do this role. Product backlog grooming is no longer entry of information in a tool or grid but is a systematic approach to handling prioritization of events that could positively or negatively impact the features in a product backlog with an unforgiving focus on business value. When products are designed and developed in vacuum without thinking through how it will be rolled out, this intense focus on business value is no longer on the radar. Depending upon who plays the product owner role (Business Analyst, Project Manager, Project Manager, Functional Manager, etc.), the nature of identifying risks morphs so much that agile projects stumble during its build (any of the releases/sprint) or as they hit the road for clients to consume. So, what are the key steps for a product owner to monitor as they maintain/groom the product backlog?

The first step to monitor the horizon for events can derail the project. The team can give some input, but the onus lies with the product owner to do the SWOT analysis and assess if the risks (Hilson, 2001) impact any of the features. This assessment could reveal new features to the backlog even on completed features. Care must be taken not to become too granular in not getting carried away for risks that impact user stories or tasks to be completed. For instance, instead of focusing on resource availability in a shared environment that may impact sprint velocity, focus should be towards eliminating risks that address training for the team to embrace agile, tools and processes to streamline communication, etc. The hardening iteration (Iteration 0) is a good place to begin this risk assessment.

When avoidance or withdrawing is not an option, the second step is to transfer the risk. Often, people skip this step and move on to mitigation right away. Sometimes, mitigation may not be the best strategy because of the detailed subject matter expertise involved, or the time commitments to deliver earlier. For example, consider the translation of voice and email notifications in foreign languages or consolidating data centers distributed globally that require specialized skills. In such cases, the third step is transferring the risk to another more informed party (e.g.: outsourcing, consultant, application service provider). 

Sometimes, transfer may not be the option leaving us to the third step of mitigation. Furthermore, even when transfer to a 3rd party is in place, steps need to be taken to mitigate the possibilities of something going wrong.  This mitigation step involves, for instance, enforcing best practice guidelines, using service level agreements, having standard operating procedures, contract review guidelines, or leveraging feedback loops to optimize the business processes, incorporate preventive actions, or take corrective actions. The sprint retrospectives are a good area for product owner that has assumed the role but not having formal product ideation training within the specific industry. This need necessitates that the product owner becomes available for the team to gather this information first-hand through osmotic communication. The more the product owner becomes unreachable, the more this risk assessment loses accountability leading to failure.

Many best practices from the mitigation strategy will still apply here, but the focus shifts more on the other responsible party, like transferring risk to an insurance carrier. For a product owner to get familiar with these trends, a more conscientious awareness of domain knowledge skills and business knowledge skills become necessary so that the product owner can make a case for the return on investment of continuing to build the product.

When none of the strategies work, the final and fourth strategy is the acceptance strategy. It is in this stage the team absorbs the risk. Yet, the product owner and the team negotiate on how much velocity can be consumed in that iteration if the probability of risk to materialize is higher. Perhaps that iteration should have more “Should do” and “Could do” features from product backlog and not do any “Must do” features. Like business continuity planning or disaster recovery planning, the product can proactively select the right mix of user stories for the team to implement to show progress but protect the team by managing risks.

All these discussions are still focusing on the fact that risk represents a threat. It is possible that risks also represent opportunities. If it is a positive risk, then, the opposite strategies apply. Instead of avoid, one exploits the possibility. Teams enhance the probabilities of opportunities rather than mitigate the likelihood of a threat materializing. Organizations prefer to share ideas to collaboratively benefit rather than transfer responsibility. 

In summary, the risk management principles are no longer just a project manager’s toolkit and are the seeds of success for successful agile implementation. They equally extend to a product owner because in an agile world, quality is non-negotiable as the product is operationalized and introduced to the customers. In fact, this is the reason why the product backlog is called risk adjusted prioritized product backlog. To embrace change, risk should also be equally invited and managed proactively. Having a product owner available to ramp up to speed with the domain knowledge of the operating business and understand the project risk management principles is inevitable for maintaining the product backlog, without which the product cannot be sustained. 

References

Hillson, D. (2001). Effective strategies for exploiting opportunities. Paper presented at Project Management Institute Annual Seminars & Symposium, Nashville, TN. Newtown Square, PA: Project Management Institute.

Thinking Differently: Transformation from Individual to a Group and to a Team

In today’s project centric, globally diverse, distributed and virtual team environment, the ability of the members in a team to collaborate is an integral part of individual’s and team’s success. Bruce Tuckerman outlined the four major stages of a team’s development as individuals become part of groups and evolves to be a team. While agile methodology may promote the need for the self-organized team within an engineering context in a product development setting, every other type of business units such as the technical operations, infrastructure, business development, sales and marketing benefit from effective team habits.

But little do many recognize what differentiates a team from a group. A set of individuals with a like mindset may be assembled to form a group but if everyone has an agenda that is larger than the common goal of the group, then, the team still not established.  The group may be best represented by the Forming and Storming stages as espoused by Tuckerman where the team is still dependent on the leader to make the decisions for the team. As the group member’s polarity on priorities is aligned towards the common business, they morph as teams entering the later stages of Norming and Performing.

Stephen Kohn, the president of Work & People Solutions of a management and training firm, along with his senior partner Vincent O’Connell consolidated their management and training experience to identify six key traits of an effective team (Kohn and O’Connell, 2007). One of these six habits includes the lateral thinking promoting how teams can innovate and invigorate by working towards common goals avoiding ineffective arguments. Often, the thinking process is associated with the systematic way of logical breakdown of ideas.

Toyota’s 5-Why principle to get down the root problem is such an example of decision tree analysis. Perhaps emanating from the control systems theory of constraints model, this hierarchical analytical thinking approach is good, but does it always generate creative ideas? For instance, how could the famous Schumpeter have predicted the “Creative Destruction” model that led to the demise of “brick-and-mortar” organizations opening the new avenues of eCommerce and eBusiness during a period of industrial automation dominated by scientific management principles?

Lateral thinking is generative and involves asymmetric pattern processing, which is not always done in sequential order, infers Edward de Bono who coined this approach in 1967 (“de Bono, n.d., de Bono, 1999). These principles are analogous to how the Agile principles promote generative behaviors through the prescriptive processes. This lateral thinking paves its foundations through six “thought” domains, called six hats. In the first domain, the team is provided with all the information available for the team to on a “fact-finding” expedition, absorb, and brainstorm alternatives. This first domain is called the white hat thinking.

The next stage leads to eliciting the team’s emotional reaction to the alternatives and decisions. Focusing on immediate reactions without any bias, this second domain, called the red hat, attempts to unearth emotional relationships. In a balanced way, the two subsequent stages evaluate playing devil’s advocate looking at the downside to selecting a solution and looking at the optimistic side of benefits of choosing the solution. These domains are called black hat and yellow hat respectively.

The next stage explores invoking additional ideas that could offset the downside and enhance the benefits like an effective and proactive risk management approach. The techniques such as force field analysis are good tools to explore for teams besides brainstorming, Delphi and Wideband Delphi approaches as they evaluate the ideas for execution friendliness if bound by time constraints. This fifth domain of additional idea generation is the green hat. The final hat, called blue hat, puts on the tactical glasses to operationalize and institutionalize the idea by streamlining the processes necessary to execute.

Great, how does these relate in real life? Say, we are confronted with a scenario of quality defects in a production application come to us. 

• Most of the “white hat” thinking would be to immediately soak ourselves in getting the details of what happened, when it occurred, how it was unearthed, etc. As the team gathers the information and evaluates the audit trail or transaction logs, the team may isolate the issue to a specific module or any systemic events. Instead of looking at the people side of the equation, effective team explores red-hat thinking evaluating alternatives and corrective action and seeks gut reactions. 
• The focus is shifting from “What happened” to “Why it happened” and “How to prevent”. Effective teams would naturally morph into wearing the black hat and yellow hat in terms of the sense of urgency to fix to address customer concern, business impact, etc. 
• While the symptom can be addressed this way, the team wears the green hat to address the root cause of the problem with a better and permanent fix to avoid similar issues affecting other customers and finally take on the blue hat to also streamline the processes by updating documents and manuals, communicating changes required, and providing training as necessary.

Isn’t it wonderful to realize the truth to the expression of “wearing multiple hats” to think differently? As you can see, the team’s ability to think laterally enhances the overall team’s ability gain trust as the organizations begin to see the team’s effectiveness in working towards the goal instead of pursuing individual agenda. As the team practices lateral thinking, the daily sprints become effective, additional meetings become redundant and unnecessary, and innovation is collaborative where together everyone achieves more (TEAM) (Temme, 1996). In these teams, the project manager becomes more of a mentor and coach, keeping the team engaged to follow the processes towards desired results.

References

de Bono, E. (1999). Six Thinking Hats. New York: Little Brown

de Bono, E. (n.d.). Thinking Tools. Retrieved April 28, 2013, from http://www.edwdebono.com/lateral.htm

Kohn, S. & O’Connell, V.D. (2007). 6 habits of highly effective teams. Franklin Lakes, NJ: CareerPress

Temme, J. (1996). Team Power. Mission, KS: SkillPath Publications