What is a successful meeting?

Meetings are everywhere.  External meetings, internal meetings, individual meetings, group meetings, team meetings, daily sprints, sprint reviews, retrospectives, etc. Then, there are governance meetings, steering committee meetings, change control board meetings, etc.

Often, people claim a meeting is successful. There are meeting notes distributed too. But what determines a successful meeting and at what cost (Rajagopalan, 2014)? I am not focusing on conducting an effective meeting on meeting etiquette but evaluating the success of a meeting.

I recall a great book on How I raised successfully from failure to success in selling (Bettger, 1992). that gave the tip. A successful meeting is one that has the next meeting identified.  But wait a minute, is that it? So, if recurring meetings are set, then aren't all meetings successful?

There lies the myth. The successful meeting is the one that needs to have clear action items identified with action owners and due dates so that the next meeting serves as a follow up. The follow through happens in between these two meetings ensuring incremental and iterative progress closing the sale, improving processes, updating progress, identifying risks, lessons learned, and removing obstacles.  If every meeting does not continuously contribute the successful outcomes desired, then, is having a meeting itself considered successful? 

If follow up meetings are proving to be action owners not providing updates or providing vague updates, then it is time to evaluate if the right owner was identified or if the owner is capable and having bandwidth. Identify escalation paths if necessary. Of course, this is true when that action item is still applicable.  If a solution is identified or closure is recommended, then it is also important to ensure collaborative commitment and if any additional follow-up would be required now or later.

Would you look at your meetings and evaluate if your meetings are successful?  What other criteria would you add outside of meeting etiquette to evaluate the outcome of a meeting?

References

Bettger, F. (1992). How I raised myself from Failure to Success in Selling. New York, NY: Simon & Schuster. 

Rajagopalan, S. (2014b). Effective virtual meetings. Retrieved from http://agilesriram.blogspot.com/2014/05/effective-virtual-meetings.html

Value of Microsoft Project Schedule in Agile Environment

One of the biggest wars in today’s software development community is the choice to use Microsoft Project Plan. In a traditional plan driven approach, the value of Microsoft project plan to know the higher-level milestones, traceability of hammock, resource leveling, earned value, project and resource calendar, unit of work, impact of delay, critical chain versus critical path, network analysis, early/late start/finish, lead/lag discussions, and multi-project/program dependency are all very well understood. 

But, when you turn the attention to agile, the story shifts! Agile focuses fundamentally on self-organized teams that manage their own tasks who are empowered to try different approaches. This is one of the reasons why the Scrum methodology doesn’t even mention a project manager role but only the scrum master role and product owner roles. But, in a truly agile environment, or a matured scrum practice, the team is almost on an autopilot! The only two needs for the team are to get clear direction and business need on what features to develop (product owner) and the support to keep deviations minimum to work on the delivery (scrum master).

But how often are the teams so self-reliant that they think of the feature outside of their business unit on the delivery? When the team is depending on the other leaders to drive this priority, interface with the product development to provide the clear direction (business need and business impact) among other things, the project manager role emerges again.  If this need exists, then, what’s the question behind the MS Project in agile methodology?

Let us think from agility. The goal of Agility is to focus on burn rate and velocity. These are good key performance indicators (KPI) in agile world in a product development setting. For instance, if we have 500 story point worth of user stories with each sprint taking up ~50 stories over 2 weeks, then, at the end of 10 iterations (discounting the hardening iteration), we expect all features to be completed. Now, say at the end of third sprint (6 weeks have gone), you are at 120 story points. We use the velocity to look for patterns in what types of commitment can be delivered by this agile team or the burn rate to project when the project can be delivered. The project managers that understand the earned value management (EVM) principles can utilize planned value, earned value, and actual cost to analyze patterns. Properly utilized, these values can come directly out of the Microsoft Project Plan even in the absence of a Project Management Information System (PMIS).

If the individual iterations are a major milestone with additional hammock activities focusing on specific user stories, then, the Microsoft Project can still be a value-added tool for the project manager to use in an agile setting. In such cases, if required, the Project Manager can still limit the focus only to the user story level tracking and should the user story become a showstopper (DONE criteria not going to be met), then, it is possible to move this story to subsequent release. Using MS Project, commitment planning can be forecasted better. Using project reports and earned value techniques, one can do similar analysis as velocity tracking and burn rate!

At the same time, think about the transparency of work required not at the team level but at the organizational level. If every team starts using their own tool, then, how do we tell the full story to the program and portfolio management, business units, and to the senior executives? This is where the use of a good integrated application lifecycle management tool comes, such as SpiraTeam, very handy (Rajagopalan, 2012). As the Vice President of Program Management Office with many different projects and programs, even though Microsoft Project, Jira, and OnTime were used originally, we found more value in replacing it with SpiraTeam (Inflectra, n.d) that supported almost all the needs of single source of truth (SST) while reducing the total cost of ownership (TCO) further. The incremental updates we have seen in SpiraTeam based on some of our recommendations and the support we have received seem to emphasize our right choice of investing in the ALM tool rather than work with a myriad of tools and spend time in using data in the backend to discover patterns.

The tool is only a means to accomplishing the work. If simple Excel or white board can be used for Agile tracking, then, to discard such a power-loaded tool as a non-agile tool is a premature exclusion of the tool without considering its benefits. The winds are changing on how the tools have emerged and so it is also time to change the sails. Otherwise, the winds will alter the course of our voyage. 

Thoughts?

References

Inflectra (n.d.). SpiraTeam. Retrieved from https://www.inflectra.com/Products/SpiraTeam/

Rajagopalan, S. (2012). Leading Change: Remote Teams can collocate on the right ALM tools. Retrieved from https://agilesriram.blogspot.com/2012/04/leading-change-remote-teams-can.html

Choosing between agile versus plan driven approach

Increasingly, I keep hearing references like the challenges and benefits to waterfall approach versus agile approach to software development. Whether these are software developers, testers, technical operations, project management, or sales & marketing professionals, the underlying theme is that software development life cycle (SDLC) has become synonymous with waterfall development but agile is not. Focusing on the core principles of agile, primarily ‘working software versus comprehensive documentation’, isn’t agile approach also developing a software? Aren’t the concepts of planning at various layers, such as daily, iteration or sprint, and release, to iteratively develop incremental software enhancements part of a life cycle for software development? So, where is the huge disconnect?

The challenge is not in the approaches but in people’s incorrect assumptions in thinking what the original SDLC proposition was and equating it to waterfall. In fact, in a recent meeting that I attended in PMI Mass chapter, many participants didn’t relate to the original author of SDLC, Winston Royce’s seminal proposition in 1970 who himself related to the challenges promoting incremental and iterative approach and the increasing involvement from project management in software development. Practitioners therefore created a non-existent and non-functional theory of waterfall embedded with the assumptions below that are challenged by my scholarly publication (Rajagopalan, 2014). 

1.       Linear approach to software development with no feedback
2.       Big upfront requirements gathering
3.       Gathering requirements upfront saves cost
4.       Analysis follows requirements followed by design
5.       Project Management is not part of software development
6.       High degree of documentation needed before starting work
7.       Customer sees work after all the work is developed and tested
8.       Testers need not be involved early

Therefore, I will deviate from using the word, “waterfall” or “traditional” approach and recommend using the “plan driven development” using the rapid application development and fundamental project management principles. Basically, the requirements for the choice of agile or plan driven approach to software development lies in the problem being solved. 

If the challenge is to build a mission critical application controlling the amount of x-ray radiation that will be discharged by a software application, then, a plan driven approach may be a better fit because of the certainty in requirements that can be reasonably predicted, and the amount risk involved in doing it incorrectly without impacting the profit margin. On the other hand, if the requirements are not certain and the complexity is not high where the functionality is possible to release in an iterative fashion such as a new mobile application or responsive website for student enrollment in a college, then, agile may be a better candidate. 

So, instead of choosing the methodology and solving the problem using the methodology, the methodology must be chosen based on the problem solved!

Thoughts? 

References

Rajagopalan, S. (2014). Review of the myths on original software development model. International Journal of Software Engineering & Applications, 5(16), 103-111. Retrieved from http://airccse.org/journal/ijsea/papers/5614ijsea07.pdf

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.

Acceptance Testing: Demystified from a business perspective

Recently in building a RACI diagram, I found questions bubbling up on why acceptance testing must be done and why that’s the testing group’s responsibility. I find it interesting to see how the responsibilities have morphed over the period on the roles and responsibilities associated with testing so that I felt compelled to write this blog article with the illustration below.

When developers write the code, the code should be error free complying with the low-level design. Since most of the code today is conceived and written in a modular fashion, thanks to object-oriented analysis and design thinking, the unit testing done at this level is focused on individual modular units. Examples would be to check for memory leaks, the use of uninitialized variables, etc. As several modules are consolidated within the package, the need to ensure the modules integrate at a higher design level comes calling for integration testing. Examples would be the passing of data between modules in a meaningful way, the use of calling external databases or webservices to ensure that there is adequate time given for timeout and exceptions so that the integrated code gracefully handles the situations. These types of testing are integral to the white box testing still at the engineering or development side focusing on the internal structure and design of the program rather than the functionality of the program.

Subsequently, the build (note that I am not using the word code) is transferred to the testers who check the workings of the program to the specifications. These testers still have some intimate technical knowledge, understanding of the database to write SQL queries or check webservices methods, write test scripts, etc. For custom projects, this group ensures conformance to requirements. This type of testing is part of the grey-box testing because the testers test for specifications but have additional access to tools for technical validation. They assure us that the quality of the software meets the requirements agreed upon in the user stories or in the business requirements documents (BRDs). Here is where the gap begins within the management community.

Those that are familiar with Juran’s definition (the seminal thought leader that laid foundation of software quality) also will relate to the need for “fitness for use” as another ingredient of quality assurance. Nobody other than the customer can evaluate this fitness test which is where the user acceptance testing (UAT) evolved. But think about how the transfer of ownership is executed in an organization. There is inexorably communication from project or account managers in custom software development or product owners in the product development to customers that the software is ready for their UAT. This is where these business owners should be held responsible for executing black-box testing, evaluating at a higher level and satisfying themselves that the software is working to the customer’s requirements. This is the last window of opportunity to identify any escaped defects before the actual customer gets involved in interfacing with the software. Then, any escaped defects the customers and end users find, or new feature enhancements identified are gathered in product backlog grooming, risk adjusted for priority, and accommodated in the subsequent iterations.

This level of acceptance testing is slowly and steadily disappearing from project, program, account, and product owners leaving the image of the performing organization at risk in front of the customer leading to trust erosion. Every car goes through a lot of quality checks but still when we buy a car, we take it for a test drive. Why shouldn’t we test drive the software ourselves before we give it to our customers? 

Cost of Quality: The increasing value of acceptance testing besides automated testing

There are two prevalent themes in software development in the corporate world: “Zero Quality Errors” and “Doing more with less”. The dominance of both these concepts has critical importance in their implementation.

1. Eliminating the number of testers increases the level of effort on the remaining testers to check every test case as thoroughly as possible introducing errors. The testers that have the accountability to ensure that they don’t release features without signing off are under pressure compromising the quality.
2. Keeping more testing resources also does not guarantee zero quality when the testers don’t keep up with the current trends. The number of communication lines increase with the QA manager, test lead, offshore test coordinators, and testers. This functional hierarchy removes the testers from the developers defeating the self-organized team requirements. Consequently, the requirements dilute and morph leading to management problems as the customer complaints increase, time to market slips, and product reviews decline.

The logical solution is “Automated testing” making the system do testing detecting more defects at earlier points in the development life cycle as well as continuously testing deployed code for production bugs. The solution is logical and practical as it accomplishes doing more work with fewer resources consistently, continuously, and almost effortlessly compared to the needs to have a human present to manually test. 

Does that mean automated testing is a perfect solution where we can enable computer assisted software tools (CAST) to as many testers as possible? The agile engineering practices recommend automated testing but also emphasize acceptance testing where the business owners also are involved in testing. But how far are our people in client-facing roles like product managers, project managers, program managers, and account managers increasing their knowledge of the business domain and related technical tools to test the releases?  How much is the management attuned to this fact?

1. The client facing roles mentioned earlier may question why they should do this testing that the testing department is accountable for? It is a valid question but when buying a car why do you want a test run? Why do we do our own walk-through inspection of the home instead of leaving the work completely to the home inspector? We do this because we are equally responsible for the outcome. As these roles face the client who can claim escaped defects or the features for enhancement, how could these responsibilities have downplayed?
2. Let us face another argument of being busy doing this acceptance testing! When automation is introduced, the developers and testers must write additional lines of code and test scripts to ensure that the automation works according to the 3A principle (Arrange what needs to be tested, Act by developing code to test, and assert by evaluating the outcome against the expected).  This needs more time commitment and learning additional tools where the developers and testers need to immerse themselves to evolve to the expectations of today’s workforce. So, if one group that is busy can increase their competencies, why should not these client facing roles elevate their skill-competency gap instead of claiming the busy life?
3. Another important angle to consider is new functional non-customer value add requirement but a business value-add requirement, such as the heartbeat monitors, exception log checks, and time taken to test checks as part of the automation efforts. None of these requirements are part of the actual product feature a customer sees but are additional scope of work that the business mandates on the execution wings to design, develop, and test. When these are baked into the level of effort or timeline and when customer asks to reduce the time to market, the client facing roles cripple the quality by not standing up for best practices.

If quality were a coin, automation testing and acceptance testing are its two sides. Efforts spent only on one side won’t have the completely desired economic impact.  Automation is a shift in the way the code is developed, tested, deployed, and monitored requiring refined skills. It is an important element in reducing the cost of quality but so is the acceptance testing that requires additional skills. If we fail to recognize and implement both these effectively, then, the efforts spent in automation may be offset by escaped defects due to lack of acceptance testing.  A new breed of client facing roles is therefore on the rise and the management needs to focus on both the automation testing along with acceptance testing. 

Adapting Scrumban to Personal Productivity

Agile approaches to product development and project management are growing exponentially. I have been a proponent of the lean approaches even at my house chores and recently found that such approaches were discussed even in the Agile 2014 conferences. Unlike Scrum’s requirements to have self-organized teams with timeboxed iterations within which changes are generally frozen and disallowed, the project management approaches do not rejoice the dedicated team. Often, the members may be spread across multiple projects like project managers having multiple projects. So, how do we manage time effectively in multi-project and program initiatives?

An approach that I have found useful is adopting Scrumban to proactively manage myself and build on the team’s innate strengths to empower themselves to do better. Sounds great, but how? Let me explain.

Scrum

Kanban

1.       Scrum focuses on timeboxed iterations with self-organized cross-functional teams. 2.       Team decides on what can be accomplished in a 2-week sprint and emphasizes continuous improvement by retrospectives 3.       The customer representative is expected to be sometimes on-site and be multi-functional with skills in product, project, account, technical, business analysis, etc. 4.       Measure of progress is working software delivery

1.       Team visualizes the workflow in queue 2.       Anyone can pull (i.e., take) any task that is in the queue 3.       Tasks are generally not dependent 4.       Balances work in progress 5.       Reduces waste between tasks

In traditional project management where resources are not procured for the duration of the project or in balanced matrix organizations where projects inherently face wait times, such as in regulated and construction industries, the project team may not be multi-functional. Therefore, it is not possible for any member of the project team to take on any project or tasks within the project. For instance, can a tester write code? Can a database architect develop deployment requirements? Can a project manager be a business analyst? While technically these are all possible in high performing organizations, other organizations may not have resources that have multitude of skills where roles can be effectively merged eliminating waste.

Here is where Scrumban comes to help. It combines the best of both the Scrum and Kanban worlds. Tasks become structured (design a program overview, develop the stored procedure, test interactive voice response for a specific Voice XML flow, etc.) to be executed by anyone within a specific group. The group or functional leader is entitled to provide the guidelines and process direction for continuous improvement reducing cycle time increasing predictability in productivity. Example, regardless of who develops the program or tests the campaign, in the given service level agreement of 5 days, the program will be developed or tested. Yet, workflow need not be limited to changes only between iterations thereby allowing new tasks to be created eliminating wait time and allowing the team to prioritize projects.

While Scrumban is a great alternative where neither Scrum nor Kanban can be effectively applied, I found out that I can use it to manage myself to be productive better in multi-project, program, and portfolio management. I have illustrated this in the above figure. From my point of view, the team is the expert, and I am just a facilitator. So, when the team has been provided with a task, it is in progress (Yellow sticky). Now, what am I doing when the team is working on it?

I don’t need to hold a meeting to check on progress – that’s project management by unnecessary meetings. But I shift my gears to what the team may be requiring next – eliminating all ambiguity for the potential next task. As a project manager, I focus on the upcoming milestone working a step proactively ahead (Blue sticky) and work with the stakeholders to get that ready so that when the work in progress is done, I am servicing the team with the next unambiguous task. This comes in handy when the team is virtually distributed because in such cases where communication needs to be both pull- and push forms, I have time to over-communicate! This is an example of what I label as 6P principle (Proper proactive planning prevents poor performance!)

Now, the more I work at this the more effective I become and so I work another step – 2 steps ahead – and work with the client, product, account or other teams to push them to deliver on their deliverable ahead so that there is no impact to critical path (Green sticky). I stop at 2 steps only because in my mind I am 1 sprint ahead and my agility hat tells me that there may be change coming that I need to prepare for.

Let us take it to the next level. May be the green sticky (Product, account, client, or other teams) can’t do anything because they are waiting on something else. Then, so much of time becomes unfrozen. Immediately, that means productive hours can be provided to another project. This is an approach to doing more with less. This next project could be part of the same program, product, portfolio or a totally different project for a different client or even developing a hobby, helping another team member, writing this article, or dedicating time for a cause. 

This is an approach I have used to timebox all the incoming work so that within the given time available, I am still able to keep multiple things moving! 

Role Mergers: Is middle management – product, account, program, and project - learning from failure?

Based on the interactions I have had with attending various webinars, seminars, networking events, and conferences and bringing them to practical work, I always ponder over a question. Is middle management – product, account, program, and project - learning from failure? I share my viewpoints on the role mergers and how many are not rising up to the requirements leading to inefficiency. 

Traditional project management roles defined frequent lessons learned or post-mortem sessions and agile development practices recommended a retrospective after iterations so that inefficiencies can be addressed. With so many different types of projects, multi-project program initiatives, products developed, and accounts managed across multiple industries, have we incorporated the lessons from our failures and most importantly other people’s experiences of failures!

My definition of failure is that if we have not learned from our failure and success, then, we have a failure. If we have learned from our failure to adjust our processes to avoid repeating the same mistake, then, we have turned failure inside out. By that definition, we can’t agree that we have benefitted from the rich experiences of failure and success entirely.

In one of the Account Management seminars that I recently attended, I heard that one of the fundamental reasons for account management failure is the lack of understanding about the products and services to provide strategic direction towards solving the customer problems. Digging deeper, Kim Zoller and Kerry Preston in their book on Enhancing executive edge relate the account management operating from a quarter-to-quarter or similar frequency on their accounts (called opportunistic) will only derail even the best project management to fail unless the account management becomes relationship based and customer focused.

But is the relationship only with the client? If we say customer focused, are we not treating employees and internal teams as customers? Think about it! Relationships with internal teams are equally important as they are the ones that deliver!  Our clients watch these things too because if you fall for everything and yield to everything the client asks then you stand for nothing, losing credibility with the client and the team.

Interestingly, Schultz and Doerr (2014) from RAIN group called out in their strategic management failure white paper that the strategic account management roles will be coming with the backgrounds of relationship lead, entrepreneur, innovator, collaborator, consultant, researcher, project manager, and skeptic. In their attempt to describe this interaction as connect, convince, and collaborate, this was an interesting finding because it brought the characteristics of a product manager or product owner of how they collaborated with the client and team grooming the backlog but also playing the devil’s advocate from both the client and the value for performing organization. It also integrated how the account manager roles need to understand the foundational project management thinking that also looks for risks, schedule, scope, cost, quality, integration, and stakeholders. Even agile teams are introducing the acceptance and behavior driven testing where additional test cycles will be added to ensure that the business team performs the acceptance testing before products and projects are released to customers.

Woven deeply in these observations is the skill/task alignment required! Technology is so pervasive today but how much technical understanding is today’s middle management exposed to! Like the saying goes in the “Die Hard” movie, “you are the wrong man in the wrong place at the wrong time!” Businesses allow many reasons to continue having unskilled or untrained resources and expect a miracle instantly! Mike Schultz and John Doerr further relate to this in “Wrong People, Wrong Roles” in mandating a minimum of three skills – leading relationships, finding innovative ways to create value, and driving your (performing) organization and (client) team to get things done. As you can see these mean that no longer are the businesses requiring skilled personnel in one area but multiple skills in other areas.

These findings resonate in the fundamental Agile principle of self-organized team! If the team depends on others to initiate, route, and manage the tasks, then agile in such cases will fail! This is also the reason why Scrum didn’t even have a “Project Manager” role in their roles merging this role with either one of the three roles depending upon the multitude of skills in the project manager – account and product management knowledge.

Keane, a consulting organization in their “Productivity Management” book recommended that productivity comes when business teams, customers, and developers are all brought into one training event to hear various sides of the productivity spoilers and address them through processes. Once these processes are addressed, the onus shits to the people! Projects predominantly fail because of people and not because of processes! Extending these thoughts even from a sales perspective, Pink (2012) recommends the new adage of attunement, buoyancy, and clarity where the sales need to engage in problem-solving more! 

Even educational institutions are not an exception and recognizing this need. In one of my recent exchanges with a University in their Visual Arts and Animation curriculum review and design, the school professors were reiterating how the expansion of cultural diversity requires learner's understanding of the target markets and industry expectations of multitude of diverse skills in the graduating learners as part of the experiential learning approach. An example is having the narrators be able to write scripts, graphic artist to know and introduce animation, public relations communication member to modify the approach impromptu when the target market for the same product has changed.

So, there is a revolution happening! Customer service is no longer one department, and it sits with every person in every department. Roles are merging in the middle management because businesses are flattening the layers and going lean in their model. So, the middle management need to wake up and smell the completion and brush up on their knowledge to be multi-faceted ready to wear many hats. If not, failures are designed to repeat!

Thoughts?

References

Pink, D.H. (2012). To sell is Human: The surprising truth about moving others. New York, NY: Riverhead Books. 

Plummer, D.H. (1995). Productivity Management: Keane’s Project Management Approach for Systems Development. Boston, MA: Keane. 

Schults, M. and Doerr, J. (2014). Insight Selling: Surprising Research on what sales winners do differently. Hoboken, NJ: Wiley & Sons. 

Differences between Kanban and Scrum

Recently when attending the 5-day Agile 2014 conference in Orlando, Florida, I had an opportunity to discuss various agile implementations. Some of the discussions centered on selecting the right type of agile methodology to consider for software implementations from extremely regulated medical devices industry and government projects where Scrum was considered prevalent. Then, when I found in my network of work and friends, there were questions that revolved around using Kanban because Scrum wasn’t working.

Having used Kanban and Scrum, I wondered why there is still confusion among the early adopters of Agile and why Kanban would be considered as a substitute for Scrum. Unclear understanding of agile concepts may lead to failure just like how people created a non-existent theory of waterfall based on inaccurate practices (Rajagopalan, 2014). So, I focus below on a comparative study of the basic premises between Kanban and Scrum. I hope this article captures the essence of these approaches demystifying the confusion and helping in the selection of the right approach for the challenge at hand.

One of the primary differences is that Kanban is a method that can be used independently or along with other approaches like Scrum. This is why we even have derivative approaches like the Scrumban.

Concept	Kanban	Scrum
Management focus	Maximize resource usage avoiding delay and enhancing accountability to support flow.	Consistent delivery in the cadence of execution, as the features in the product backlog is delivered.
Operating rhythm	No time-boxed iterative development exists.	Time-boxed iterative development – usually two to four weeks.
Granularity of work	Focus is at the task level for which the scope of work is generally known.	Focus is at the user story level for which the scope may not always be known, requiring it to be estimated before tasks can be identified and taken up by the team.
Agile Estimation & Planning	Estimation is generally not done. There is little to no ambiguity on the task that any member of that team should be able to take on the next available task and execute it.	User stories are estimated. Then, they are prioritized, and risk adjusted so that these are included in the release and iteration planning.
Value Delivery	Every task completion may not necessarily add minimally marketable value to the customer. Task identification and dependency require careful coordination.	The cadence of release and iteration planning focuses on adding minimally marketable feature through the scrum cycle. The self-organized team determines the task identification and dependency.
Progress Tracking	Flow of items throughout the lifecycle limiting delay. This is why the focus is on limiting “Work in progress (WIP)” is promoted through “Don’t Repeat Yourself (DRY)” focuses on maximizing work not done	Focus is on tracking the velocity measuring the user stories done and delivered to customer in an iteration
Utility value	Better for managing workload and resource management. E.g.: How many projects of different combinations can be taken up by a project?	Better for managing products, programs, and projects.
Thoughts to consider in software development	Use of Kanban for software development may impede flow if all the units don’t consume the work produced at the same speed. Therefore, additional processes must be in place to support Kanban. E.g.: QA not having capacity to test code developed by engineering team. If QA’s capacity comes from the fact that more defects are found in the build, then, more granularity in tasks to ensure proper code review, unit testing, and documentation are processes that the organizations must have in place.	Implementing Scrum doesn’t mean the ability to write user stories and avoiding documentation completely! This requires a management shift to ensure critical thinking on the product, program, and projects. If iterative delivery is not understood by the management and client, then, Scrum is not an option to consider.

In summary, Kanban and Scrum are both light-weight approaches, but the operating philosophy is different. Scrum focuses on the work being delivered to customers through multiple iterative deliveries of minimally marketable value by assembling a cross-functional, skilled, and self-organizing team or team of teams. Kanban, on the other hand, is a pull-based system and focuses on the visualized workflow where flow is maximized by limiting what gets worked on by the team. Although both approaches require prioritization in the items represented in the backlog, Scrum team can’t pull an item outside of the Sprint backlog when they have capacity. Kanban team can pull the next priority item from the backlog. So, depending on what product, service, or result the team is delivering, or the benefit being sustained in operations, Scrum, Kanban or Scrumban may work. Select the right tool for the right job!

Thoughts?

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?