Starting the Problem Half solved: Strategic about Successful requirements gathering

In one of the recent round table discussions that I spoke on the differences between traditional and agile approaches, it became apparent to me that there was some disconnect in the notion of what constitutes a requirement. The software development approaches leveraging traditional plan driven approaches to project management focuses on scope planning activities that centers on requirement definition because it is well known that a successful definition of the problem means we have the problem half solved.

Considering the developments in agile approaches to project management where change is welcome even at later stages in the development, the gathering of up-front requirements is often frowned upon. Although the requirements definition may be a daunting task when there is ambiguity around it, value delivery happens only when an attempt is made to eliminate such ambiguity. When client facing members fail to ask powerful probing questions and engage the expertise to eliminate some level of ambiguity, the business goals are often compromised.

For instance, a requirement should at a minimum address what the software must to do satisfy what the users need so that the value is maximized, and benefit is realized. On the contrary, if the requirements are conflicting and attempts made to eliminate ambiguity are thwarted, then neither the traditional nor the agile approaches to software development will benefit. As the movie, Apollo 13 calls its mission at the end, such requirement gathering from the beginning can only lead to "Successful failure."

Readers are directed to check out an interesting video at this point to gather some insights into the incomplete requirement gathering This video is on youtube at https://www.youtube.com/watch?v=BKorP55Aqvg. What went wrong here? A few thoughts are as follows. Share your thoughts.

• Is starting immediately with a “No” a good approach?
• When trying to ask what the end result will look like, is attempting to over-please rather than understand the business goal appropriate?
• Is both the client facing person and the project manager on the same team as the expert?
• Were any attempts made to negotiate for an acceptable best alternative?
• Is this project setup to succeed?
• Is this a productive meeting?

What powerful questions can you add to ensure that redefine the requirements correctly? Stepping outside of this video into our own projects or products, what additional questions can we ask to understand the client’s requirement and the reasons behind the requirements better to position ourselves for success?

Abuser Stories:What shouldn't the software do?

The general tendency of the requirements document has predominantly focused on what the software should do. In project charters and scope control documents, sometimes we also write what features will be out of scope. The UML diagrams and use cases discuss how the classes should interface, and modules should interoperate, for instance. The agile paradigm discusses persona approaches drilling down DEEP property for describing backlog features and INVEST principle elaborating on the characteristics of a user story. Even test cases that focus on negative testing use a requirement traceability matrix to the requirements limitedly testing the functionality of what a system shouldn't do.

But, when a system is hacked or inappropriately accessed, the loopholes rests on the inefficiencies in how the system was designed to allow such loopholes to exist. So, how do you avoid these vulnerabilities so that the hacker doesn't exploit these "working as designed" gaps?

While volunteering at the Agile 2015 conference, I chose to attend a section on Abuser stories by Judy Neher from Celebrity Technical Services. It was a great session introducing the concept that a persona of a hacker or disgruntled employee could potentially have a malicious intent to deliberately break the system. The speaker suggested describing user stories that specifically could break the system or expose the system for malicious intent. The participants in an activity gave examples for a simple user authentication such as the stringent password recycle policy, the use of a double password and picture identification, the use of external devices such as phone, email, or mobile texting to use tokens for validation within a short timeframe before the account is locked, the creation alerts for maintenance for incorrect and frequent access to multiple accounts, the enforcement of HR exit policies on employment dates before the role based access can be authenticated, the validation of human versus robot logging by tracking the speed of password entry, etc. Imagine having such stories to bulletproof the system against malicious attacks on standard user stories and have automation capabilities to constantly check for these loopholes.

I am sure one would say that this would add more time to the scheduled release or limit the stories written per iteration/sprint. Of course, like non-functional stories that add some time, the abuser stories also will add time. The need to develop hunches on the type of regulations in the industry, the type of technical platforms used, the time to market considerations, etc. However, the question shouldn't be whether to do them or not but when to do them. If we fail to do them, we are increasing the technical debt. A couple of alternatives are to dedicate a sprint or a portion of every sprint to address these abuser stories.

I really think this is an important component of combined technical and product ownership to ensure we see the persona of other types of users and see the system from that view. As good project managers turn assumptions into risks and control quality, the technical and product owners should be accountable for products that preclude vulnerabilities by design. Abuser stories are a great start. Don't you think so? Share your thoughts.

References

Neher, J. (2015). Abuser Persona. Agile 2015 Conference. 

Attention or Time Management

Flying over India returning from Mumbai to Chennai, I was browsing the Jet Airways magazine. Often filled with travel recommendations and shopping suggestions, these in-flight magazines have only created a browsing pleasure. But this magazine had a topic on achieving more with less perking my interest to explore.

It was an interesting read as the article began discussing how  time management pretty much shouldn't be the focus of smart managers. Instead, the article focused on attention management. Based on the time of the day, people can manage difficult tasks that require deep thinking, strategy, etc. when their attention to detail is at its peak. Then, as the energy winds down, their attention takes a deep dive. This time should be used for tasks that require less critical thinking.  Between these extremes is the reactive attention seeking time zone that should be used for other tasks that require a balance of the two.

I agree that it is a good idea and that tasks require different levels of thinking. For instance, planning for the project, evaluating strategies to grow accounts, or grooming the product backlog with new features based on the market and reactions from customers and users require thinking different from task or resource management.

However, the article said the urgency of the tasks shouldn't be a criterion for attention management.  This begs some thinking as depending upon the role of an individual manager, the urgency of the task, such as a grieving customer on the phone, an infrastructure deficiency leading to business continuity management, or a delayed or poor-quality work impacting deployment readiness of a project is not something that can be ignored.

The earlier approach on using Scrumban to think a couple of steps ahead and plan can be combined with attention management to better compartmentalize take at hand and energy/attention requirements to better manage productivity.

Thoughts?

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

Risk Managemeent: Key to Advancing into Program Management

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

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

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

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

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

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

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

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

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

RACI: 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.

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?

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