Agility outside of Software Development: A case study from a Theatrical Play

In the ever-growing need for agility in today’s business context, the principles espoused by agile Manifesto have emphasized enhanced productivity, increased customer satisfaction, and improved profitability. As noted in the previous blog entries, these principles are so entrenched from the software development practices that one of the foundational agile manifesto principles values working software over comprehensive documentation. Does this mean then that IT projects establish the glass ceiling for the agile principles?

As a member of the Chicago Tamil Sangam’s recent venture to stage a historical play, “Ponniyin Selvan” (n.d.) that was staged on May 4, 2013, we staged a historical play in the Tamil language. Centered on a course of events that took place several centuries earlier, the play presented several unique challenges that were overcome by applying some basic agile principles breaking the glass ceiling demystifying how these principles can extend outside of IT projects.  

The limelight of the play was its backdrop set in 11^th century Chola Dynasty in ancient India that weaved several challenge threads, such as the following, that needed to be collaborated to allow the finished fabric shine.

1. Preparing rich costumes, jewelry, and artifacts to differentiate the Emperor, the Kings, Queens, Ministers, and workers that required coordinated efforts to identify the needs among the actors, procure items necessary from India, and get them shipped from India.
2. Identifying the needs of the auditorium based on the play requirements, distance, transportability and audience needs
3. Designing several high-end artifacts that were transportable with easy assembly, such as preparing backdrops suitable for the play, two boats that moved, a ship with effects to display shipwreck, a palanquin as an entry point for the character, and pillars establishing the authenticity of the 11^th century
4. Rehearsing the play spread over five volumes perfecting dialogue delivery, enunciation of words, clarity of voice projection, light cues for various spots on the stage differentiating progress of characters and events through various backgrounds, preparation and coordination of musical clues, singing and dance choreograph appropriate to the characters, body language clues collaboration such as when to pass the message card or the crown, how various characters should see during critical scenes, 3 full length exams including a daylong marathon practice sessions.
5. Advertisement and marketing efforts on social media, press, and soliciting appreciation from prominent external representatives, such as the President of India, increasing the reach
6. Subsequent preparation for the main event date with food and supply for the crew, makeup needs, and transportation of goods, stage preparation, and coordination of light clues with the auditorium crew that didn’t speak the regional language, backstage line up of cast during the play informing what scene is in progress
7. Addressing challenges for audience lineup, food distribution, parking lot and law & order challenges

Do any of these resonate with agile thinking that many reserve for software development projects? Let us revisit the Agile Manifesto (n.d.) and evaluate against this stage play.

Evaluation of the First Agile Manifesto Principle

The first Agile manifesto principle recommends “individuals and interactions over processes and tools.”  While following the audition, the characters were formed, several self-organized teams evolved that took on preparing specific artifacts. While marketing team operated separately from the teams that designed the costumes, prepared the ship, palanquin, backdrop, pillars, and boats, every team led communicated updates through the distribution group, on specific phone conferences, and provided incremental updates. So much was the focus on the individuals and interactions that when one member felt challenged by a work schedule, business trip, or a family emergency, there were so many willing and helpful members that came to assistance. Every team meeting ended up with a summary of the next action items following the same basic principles of what progress has happened, what progress is expected before the next meeting, and what the challenges were trying to create a win-win situation for all.

Evaluation of the Second Agile Manifesto Principle

“Working software over comprehensive documentation, “says the second Agile manifesto principle. While it is true that iterative delivery of working software makes the user experiment with the software mitigating the risk of failure, enhancing speed to market, and satisfying end user experience, can we rethink what software is? 

How many of us will travel on a bridge that is functional for the first 200 yards, but the remaining 100 yards are not yet constructed? How many of us are willing to buy a book that has the first three chapters written but the next 3 chapters are in script review? As you can see, in some cases, the end result has to be a fully functional system or product and not a partially working product. This play required that all the 50 scenes are seamlessly orchestrated and not just partially done. However, the challenges of the working individuals that made up the cast or the stage preparation crew that had overlapping members with cast, required we divide and conquer using iterative releases.

Dividing scenes of the main events in the play, the cast was informed to memorize the lines, rehearse their dialogue, and practice their songs with every weekly iteration and monthly releases over approximately 6 months rehearsing specific scenes in the sequence, making progress in preparing artifacts, checking the costumes, perfecting dance, singing, and fighting sequences of the play. There were even members invited only to provide constructive criticism using index cards presenting the user stories. For instance, one of the index cards read, “As a minister to the King, you should not use too many hand gestures to show your surprise so that the audience knows that you are always composed and thinking of the next scheme.”  Even the venue selection for the 40 individual practice days was so distributed to address geographical challenges to collocate the team to benefit from osmotic communication in that everyone could manage to attend understanding stage movement clues, voice projections under different audio systems, as well as including phone rehearsals to perfect dialogue delivery to combat.

Agile does not say “no documentation” but only “comprehensive documentation.” But the extent of required documentation is left to the individuals in the team. While there was no specific documentation created on how to assemble the palanquin or the shipwreck scenario, there was a substantial documentation created with more than 150 light clues on what area of the stage had spotlight, when there was colored light, when the light flashed to add special effects, etc.  Similarly, there was documentation on the backstage collaboration as stage, scene, and individual props moved seamlessly through worksheets identifying who moved and removed properties to the stage, where they moved, how they moved, and communication protocols to the custodian that gave the cues to the light crew sitting far from the stage.

Evaluation of the Third Agile Manifesto Principle

Agile manifesto values customer collaboration over contract negotiation. Again, real life scenarios such as these stage plays challenge the common thinking of who the customer is.  In business parlance, the customer is the one that pays for the product or service and is the reason why the company is in business. Extending the same terminology would mean the audience that came to see the show or the sponsors that supported the show were the customers. But this stage play extended the notion of customer far higher, such as the following instead of going back to “what you are supposed to have done” contracts based on the rehearsal.

1. A character is a customer when talking/interfacing with another character. So, even when the lines and body language were rehearsed, the team didn’t wait for the cue words that went missing but filled and moved on.
2. The light crew was a customer to the character on stage and when the character in the spur of the moment was on the right marked spot to deliver, the light crew attempted to refocus the light.
3. The cast themselves were customers to the stage crew that required the individual properties to be returned to them for reuse in other scenes. However, when one member missed it on stage or left it on different section of the stage, the backstage crew or the experienced cast members accommodated to keep the show moving without backlog.
4. The self-organized team was so focused on the goals that lines of who was the director/facilitator (product owner) or who was the process checker (scrum master/coach) never needed to surface. So tightly integrated the team was that they even altered their international and other business trips to attend rehearsals, participated in phone rehearsals from taxis, cabs, and hotels during their business trips. The “How may I help?” message and motivation support was so evident among the cast, crew, organizers, and volunteers.

Evaluation of the Fourth Agile Manifesto Principle

Finally, Agile recommends responding to change over following a plan. Although Agile may promote this value statement, this value proposition is emanating from common misconception of traditional project managers that think, “Plan the work and work the plan.” Fundamentally, such purist project managers are those that came to the profession accidentally thinking that working the Microsoft Project plan and being a task master is all that this Project Management means. Contrary to this belief, experienced project managers whether they follow Agile or Waterfall, know that no project goes by the tasks laid out in the work breakdown structure (WBS) of the project plan exactly. If they do, why is fast tracking and crashing approaches exist? 

1. In the stage play, several “gotcha” moments existed. A few examples include the following that emphasize how the stage and crew adopted to change instead of reacting to we should stick to the plan. People that failed to project their voice or speak closer to the microphone got directions from the crew or other supporting cast on stage using body language to direct them to speak louder.
2. Microphones that did not pick the voice adequately from where the throne was located requiring the cast to adjust their movements requiring them to “be in the act” walking closer to the microphones.
3. Using incorrect clues from the stage coordinator to the light crew that started the scene prior to the backdrop swap was completed requiring to readjust the plan as the volunteers got stuck behind and could not be readily available for the next stage transition.
4. Realigning the position of the location of the palanquin and using a different spotlight from the originally approved light sequence when the microphone needs challenged the available moving space for the cast.
5. Altering the movement of the boat movement sequence requires using the entire stage area differently.

Summary

In a nutshell, this stage play is one of the several testimonials that Agility should be in one’s mind first. Agile Manifesto might have started as guiding principles of software development, but its application is not limited to the software development projects.  It is important to understand that everything Agile is subjective and not definitive. This is sine qua non of Agile Project Management. The goal of the iterations or releases are incrementally building progress towards the end goal and the role of the product owner or scrum master is to be authentic in their leadership so that the group buys into the goal becoming a self-organized team. Then, the teams don’t just break a leg! They make history.

References

Manifesto for Agile software development (n.d.). Retrieved May 11, 2013, from http://agilemanifesto.org/

Ponniyin Selvan (n.d.) Retrieved May 13, 2013, from Wikipedia http://en.wikipedia.org/wiki/Ponniyin_Selvan

Agile's Amigo: Process

Stuck in flight delays at the Airport in the last few days, I was sitting at the Gate near the corner of a terminal where I could see through the glass windows the crew that was using the back doors along with the customer service representatives answering the stranded passengers and interacting with the flight crew for boarding preparation. Simultaneously, maintenance crew was inspecting the plane, another group loading the baggage, and yet another group fueling the plane. None of these various groups were visibly communicating among each other at the same time but the whole flow seems so orchestrated. If getting the plane to fly were to be considered as an agile project, then, the tasks associated with checks and balances is so much grounded in process which made me reflect on some comments by a few agile practitioners that there is no value in process documentation.

It is true that Agile Manifesto associates a higher value to “Individuals and interaction” over “processes and tools” and “Working software” over “comprehensive documentation.”  But does Agile truly suggest not having any process to follow or ignore writing any documentation? Let us challenge the agile purists then why is Agile so heavy requiring a process to capture user stories to have some minimum qualifications emphasizing the INVEST principle and backlog entries to follow a DEEP property? Why the developer can’t be left to interpret what should be developed instead of requiring to also understanding how it should be tested?  One may then associate that such silo-ed thinking may lead to failures from waterfall to repeat requiring collaborating using the daily sprint and using the agile dashboards for communication.  In that case, let us reflect further.

1. If projects are successful because of people, then, let us also accept that not all people absorb and consume information at the same pace even in a self-organized team – requiring at least some level of process enforcement such as the same repeated questions used to uproot challenges in a daily sprint. Isn’t this some level of process?
2. Even from a pure engineering and development standpoint, then, why is Agile putting such an emphasis on Refactoring going down to the level of documenting specific smells (Agile terminology indicating a symptom of a problem) collapsing classes to simplify object inheritance design, long parameter list, and even recommendations of how much should be in a specific try/catch block? Isn’t this substantial documentation of processes to be used in agile projects?

Most of the contributors to the agile manifesto came from a strong technical background with a focus on developing IT projects. The logical breakdown of thought process is inherent in the IT discipline. Yet, these practitioners carefully drafted the four manifesto statements where processes, tools, comprehensive documentation, contract negotiation, and following a plan were not considered effective or essential. To those agile practitioners avoiding creating documentation or valuing following a process, let us emphasize that Process is the Agile’s Amigos! 

Project Quality: Whose job is it to guarantee it?

In a series of training that I was recently providing to project managers, software testers, and business analysts, I found discussions that focused on who was responsible for software quality in projects. The project managers thought it was a QA department role.  QA passed it back to requirements form business analysts who then delegated to directions from the project managers.  With so much literature on total quality management, Six Sigma, capability maturity model, and organizational project management maturity model, it dawned on me that it is this inherent lack of ownership for quality is the reason why quality is suffering in many projects.

Basic requirements of quality are often described as adherence to requirements and fitness for use.  When you look at the key deliverable of this statement, “requirements” stems from the project requirements. In traditional projects, this requirement may come from the client, business analyst, project manager, or the product owner at a minimum. In agile projects, this could be coming from the product owner or client, scrum master or coach, and the team at a minimum. The “fitness for use” stems from timely release of the futures to ensure that the client can benefit from the release.

But does this definition unambiguously tell whose responsibility quality is? The Chartered Quality Institute comes to rescue as it defines quality management as a company’s approach to “…understanding precisely what customers need and consistently delivering accurate solutions within budget, on time, and with minimum loss to society.” (“What is Quality”, n.d., para 1) This definition emphasizes quality within the project constraints budget and time limiting the focus to the scope of the project’s requirements but also to the needs of the society relating to the fitness for use. A project manager is not developing the code or involving in the execution of tests. But quality is the fourth constraint that is compromised as the other project constraints are modified. Therefore, the project manager is accountable for the quality. This is why Quality Audits are associated with the project manager (or product owner).

It reminds me of the famous parable on the virtue of citizenship from the “Adventures from the Book of Virtues.” Many subjects in the kingdom complained about many things in the kingdom and not taking true ownership for improvement. The king hid a pot of gold beneath a big boulder and waited to see who took leadership for removing the rock enhancing safety and quality experience for the others that passed by.  Quality is the same thing as the citizenship requirement. It is everyone’s job. The more structured approaches the organization uses in testing accuracy through automation, test case development, and test execution, the more the project manager becomes attuned to following through on quality, the more the team members will become focused on providing quality by design rather than expecting it to be accidentally evolving.

References

What is Quality? (n.d.) The Chartered Quality Institute.  Retrieved March 28, 2013, from http://www.thecqi.org/The-CQI/What-is-quality/

Agile – Is it a Panacea or a Placebo?

It is true that the fundamental twelve principles of Agile Manifesto (n.d.) have helped many projects succeed in organizations. These results are evident in the increasing 61% of agile practitioners promoting the adoption of Agile in organizations, as noted by the 7^th annual state of agile development survey conducted by Version One. But, several agile purists focus on some of the buzzwords, such as the Test Automation, making it as though Agile is the cure-all for all business problems.

Those in the technical world may understand the famous statement, “Not all business problems are nails to use the same hammer as the tool,” when common object request broker architecture (CORBA) was initiated to introduce by Object Management Group (OMG) the communication between software components regardless of the underlying language used to develop them. However, it is interesting that some agile practitioners are inclining towards test automation as a cure-all (panacea) treating all test cases alike.

Testing requires two basic requirements namely verification and validation. Verification is the process of evaluating test cases, test scripts, requirements or user stories to ensure that the process of testing is going to ensure that the required functionality is present to meet the user requirements. The focus of verification is on the process and is therefore an improvement process oriented towards assuring quality (QA). But validating is the ongoing approach to testing the software with the goal of identifying defects. These defects could be traced to the faulty code, inaccurate design, incomplete or ambiguous requirements, misinterpretation of the requirements, or a combination of these factors. Validating therefore aims at controlling quality (QC).

So, test automation can help in the validation to ensure that every incremental build is tested for the new features but also for the previous features. It is therefore not a placebo but is not a panacea for all business problems. Depending upon the unique business requirements, some requiring can’t be easily automated even if technology can allow it. For instance, testing the human interfacing with the interactive voice response (IVR) at various points in the call flow to check for the disposition code, checking for the line breaks in the email, or the accidental mix up of Far Eastern Asian Language characters because languages such as the Chinese, Japanese, and Korean share a common base do benefit from manual testing.

It is therefore important to evaluate what is the business need in test automation and identify areas that can lead to efficiency gain. Redman and Nielsen (2013) very nicely paraphrased Deming suggesting to carefully select the right process to automate explaining “… automating a process that produces junk just allows you to produce more junk faster". Deming might have inferred this long before the agile was conceived but some golden principles do stand the test of time.

References

Principles behind the Agile Manifesto (n.d.). Retrieved February 13, 2013, from https://agilemanifesto.org/principles.html

Redman, T.C., & Nielsen, D. (2013). Computerization in Health Care Demands High Data Standards. Harvard Business Review. Retrieved February 28, 2013, from http://blogs.hbr.org/cs/2013/02/computerization_in_health_care.html

Project Managers as Change Agents

Recently, when I was training on the agile project management framework with Scrum, one of the learners questioned why retrospectives are necessary after every sprint. In another isolated meeting, an underlying process challenge was identified by the Project Manager, but a lessons-learned session was never conducted. The project manager reasoned that the project is not completed to do a post-mortem. These observations underpin an important role of the project manager in waterfall or agile driven project to be a change agent.

Organizing the project is not just about conducting meetings, maintaining a project plan, or communicating status updates. A Project Manager must under the larger holistic need of the purpose of the project – a vehicle for the organization to deliver a unique product or service. Whether such initiatives or research oriented, internal, or client facing, the project manager’s role is a supporting activity as Porter’s value chain approaches indicate. If there is a process change identified from one implementation of the project, then, such issues need to be escalated to address the gap so that another project benefits. The Project Management Book of Knowledge (PMBOK) captures this essence emphasizing that the project management activities should be aligned with top-level business direction, and if there is a change, then project objectives need to be realigned. (2008)

To accomplish this need to maintain the alignment, the lessons learned must be as frequently conducted and reported. For instance, think of a module in a program that is having an issue. If the issue is in the core library and is identified, fixing the issue helps all the modules that will leverage this common module. Similarly, if one project identifies a process gap, then, conducting lessons learned to communicate the need and identify an action plan to address the issue will help the other projects. In this process, each project adds incremental value beyond the benefit of one project alone.  A project manager is not just a ring master routing tasks but is more like the performers on the swinging trapeze constantly and gracefully extending arms to support the other performers. 

References

Project Management institute (2008) A Guide to the Project Management Book of Knowledge (PMBOK). 4th Edition, Project Management Institute, Newtown Square.

Importance of Domain Knowledge for Project Manager Excellence

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

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

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

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

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

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

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

What do you think?

Will tools make up for an effective Project Manager?

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

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

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

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

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

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

New Breed of Project Managers

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

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

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

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

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

PMO Metrics to Support Governance Needs

In the world of metrics, it is critical for a program management office to focus on critical measures for governance or steering committee. Which each project can focus on EVM measures, WIP, velocity or the burn rate depending on the project, not all these metrics are relevant to the sponsor or the senior executives. As the head of the Program Management Office, I provided monthly updates through my program management office portal, but I worked with the senior executives on exactly what types of metrics were relevant at a governance meeting for decision-making! 

Eliminating some of the proprietary information given below is what I negotiated and agreed upon with the senior executives. 

1. % of completed projects delivered ahead of schedule for a specific date range.
1. Computing the following for every In Progress project in each date range using (Actual Finish – Baseline Finish) / Duration delivered projects ahead of schedule despite the delays.
2. Show in percentage the number of projects ahead of schedule (negative slip) and behind schedule (positive variance) in relation to the total # of In Progress projects.
2. Launch Measure: Schedule lip from "Actual Deploy Finish" from the original "Baseline Finish"
1. This measures details on the slip. Compared with the phases that slipped, the major contributors for delays are analyzed using DELAY tasks.
2. If all resources are using proper resource guidelines, then, the slip can be computed as :(Actual Finish – Baseline Finish – DELAYS) / (Total Project Duration).
3. % of healthy and unhealthy Projects
1. This measures what projects need attention for scope creep, schedule sleep, budget overrun.
2. Enforcing the color codes as an indicator, % of projects that have all the three constraints in green compared to the number of projects in progress.
3. A project that has any one component red is marked red.
4. A project that has no red issue, but any one component yellow is marked yellow.
5. A Project that has all the constraints green from all members is marked green.
4. Critical Risks and Operational Issues
1. Measured across the programs based on production issues impacting client satisfaction and business objectives
2. Evaluates which program or project level risks materialized that required attendance or what new issues caused the operational challenges
3. Discussion points should involve RCA on each issue from both corrective and preventive action

The Senior Executives could always get these reports within a day's lead time and the PMO continued to be effectively running with these metrics. No surprises to any program or project managers as well as the product and operations managers. 

Earned Revenue - Financial Framework for Client Programs

It is common in some industries to have statement of work (SOW) or agreements that span multiple deliverables. Projects executed according to this contract have delivery-based funding guidelines such as 25% at agreement signoff, 25% on delivering the first benefit, 25% upon transition, and 25% after 3 months of benefit sustenance covering the warranty period. In other complex client agreements that span a program, there may be multiple smaller components, each having its own benefits as well as a deliverable-based delivery schedule. It is important for the Program Management Office to track such overall funding to individual projects and the various types of fees. In the absence of such clear financial tracking on projects, it becomes difficult to determine how much of the allocated amount has been earned by the performing organization especially when the client cancels one or more components of the program or terminates the entire initiative.  This is the case with life sciences and pharmaceutical space where my existing company operates. 

Due to the lack of such project based delivery funding allocation mechanism, revenue was lost when clients canceled or when change orders were not properly filed to add funds to the program or project component for operational activities such as additional email sends, direct mail drops, or increased number of changes received from the medical, legal, regulatory (MLR) teams from the client organizations that neither the brand manager at the client company nor project/program managers of the performing company had complete control on.  This is when I introduced the concept of "Earned Revenue". It is not the same as earned value management (EVM) but is a financial method. 

In this approach, when contracts were received, I worked with the sales and account management team to get a breakdown of the cost. This led to the pricing model through which the overall amount for the various campaigns (each campaign was a project) of a larger program (brand). Each project had its own costs such as management costs (MLR meeting and travel time), development costs, fulfillment costs (sending educationally relevant items (ERI) to the physicians, Recruitment Costs (costs to acquire physicians and send emails and direct mails), incentive costs (supporting fixed price incentive fee schemes), and additional program costs (not shown in the diagram below). When change orders were initiated, they were tracked at the individual projects (as shown below). By breaking down the program costs into these individual areas for every campaign, the actual project work was mapped to the delivery estimate. 

Please note that this PMO Portal is something I developed with role-based user access to the project managers and other stakeholders (account and finance team). All references to any project in this diagram are deidentified. 

As a result of this approach, there was increased visibility to the granularity of work done in the program and in the individual projects. Say when a program had 4 campaigns with its own breakdown of costs addressed in this way. Then, when campaign 1 is closed, campaign 2 is in transition, campaign 3 is 50% done with the development, and campaign 4 has not started yet, then, when the client canceled the program (due to budget cuts or opportunity no longer relevant), then, we were able to recognize 100% of all the amount for campaign 1, 75% for the revenue for campaign 2, anywhere between 50%-75% for campaign 3 and 0% for campaign 4. It helped with giving back money for which work was done as a performing organization and established guardrails for both the client and the sales teams on how much money can be recovered upon cancelation. 

The notion of Earned Revenue is not something that is present in the Project Management Book of Knowledge, but I am thrilled at introducing such a financial allocation method!  Yes, the finance was ecstatic about this approach and the sales, account, project, and operational teams didn't feel they were doing free work for some projects. 

Raising the CURTAIN on Requirements Management

Managing several project managers at various levels of project management maturity and a few business analysts that have specific domain knowledge but not the broad business knowledge, one thing that I often find struggling is for the project managers and business analysts to work with their clients in understanding the gaps in the requirements. Requirements Management is not the same as Scope Management. The latter is clearer than the former and needs one to wear the critical thinking to see the strategic value, organizational benefit, etc.

Whether one is responsible for the project, program, portfolio, or product management, starting with the “why” behind the strategic value and benefits framework is very much needed. The field of systems thinking truly helps here. Some of the foundational systems thinking questions that you can combine with the “Five-Why” approach are listed here. Getting the answers to these questions from your own research or from stakeholders will ensure that you have good requirements, to begin with.

•       Where are you today?

•       Where do you want to go?

•       Why do you want to be there?

•       What are you willing to prove by going there?

•       What are you willing to give up getting there?

•       How do you know you have reached?

So, depending upon the scope of our initiative, short-term or long-term, project, program, or portfolio level work, the type of requirements evolves from high-level to low-level continuously. Therefore, the requirements have a lifecycle. The practice standard for requirements management also emphasizes this by coming up with six stages. 

1. These start from the Needs Assessment. 
2. Then, we move to the operating structure and governance framework within which the requirements are managed. 
3. Then, we move to the process of eliciting requirements through document analysis, interviewing, observations, market research, brainstorming, focus studies, and so on. 
4. As we gather the requirements, we analyze them for the value they would add. A simple measure to evaluate is the return on investment – In other words, does the time and money invested in addressing that requirement add value? 
5. Then, we monitor the changes to the requirement through the voice of the customer and voice of business as we iterate through the changes.
6. Finally, we evaluate the solution delivered as the product moves through its lifecycle. 

While these concepts are easy to understand, they are also difficult to implement. A simpler approach to apply this thinking was required. So, I came up with an approach where people can question whether any requirement from the client can be validated. I called this technique "CURTAIN", and it stands as follows:

1. Concise:  State actionable information without any unnecessary information
2. Unambiguous: There should not be more than one way to interpret the same information
3. Realistic: Deliverable within the constraints of scope, schedule, cost, quality, and available resources
4. Testable: Requirements should withstand a “pass” or “fail” criterion
5. Atomic:  Every requirement should be unique
6. Independent: Understanding the requirement shouldn’t depend on another requirement
7. Necessary: Removing the requirement should affect the system/product

This approach helped most of the business analysts and project managers. Hope that helps!

Let the birds fly: Experience launching a Program

Earlier in 2010, I was consulting as a Senior Project Manager, for Physicians Interactive. We signed a major program with a pharmaceutical client in the treatment of infectious diseases (disease state and pharma name deidentified). This program had three different drugs (or brands) that had their own individual mechanism of action (MOA). Each brand had its own brand manager (program manager) at the client side overseeing the numerous FDA approval process through the independent medical, legal, regulatory (MLR) board (think of it as the program steering committee), promotional activities, and adverse event reporting among other things. 

The program that we signed was a major "integrated program" with the pharmaceutical company. Each brand had a focused short-form branded newsletter with an interstitial small-form video, sometimes with a key opinion leader speaking to a specific point, or an animated video on a specific indication that could expand the application of the drug for a targeted patient population. The interstitial video will automatically land in a landing page that had additional resources, such as reference materials and coupons available, applicable for that brand. This landing page had two additional things as well. One was a link to a longer form video content that discussed for 3-5 minutes more information such as the PKPD (Pharmacokinetic-Pharmacodynamic) processes, treatment considerations, patient population limitations, etc. The other was a link to the longer form video content related to the other two drugs. 

So, in theory, this was great! But, in practice, we created a monolithic large program that couldn't be launched. It required all brand managers, medical science liaisons, legal and regulatory counsel, and each program's change control board members to come together and align on the combined overarching strategic goals to ensure that the benefits can be delivered to the physicians (customers) and eventually to the patients (end-users). We practiced waterfall rather than agility! 

Launching this program was so difficult because one brand will request changing something on the landing page that required approval to another brand's approval process. Since each MLR team had their own planned steering committee meetings that was closed to anyone except that brand's governance team members, it became difficult for me to get everyone on the same page to align on the changes required. So, even though the newsletter was ready, we couldn't launch it because of the dependency on the interstitial video component. When both were ready, we couldn't launch either of them because the landing page was not approved for launch due to the dependency on another brand's outstanding changes to this landing page. 

So, I escalated the dependencies as a risk with a diagram that diagrammatically depicted these risks. I positioned my points on how such an integrated approach fails to deliver value for the pharmaceutical company, the three brands, physicians, and patients besides our ability to launch the program continuously putting change orders for increased work! My request was two-fold: 

1. Goal: Reduce the Waiting Time. I asked to the three program boards to open the steering committee membership to me, the other three brand managers, and a medical liaison from each brand to ensure fair balance. This would mean that when one brand's MLR team made a change to anything that the other brand's MLR team needs to weigh in, time is not wasted in getting these points across and communicating this feedback back to them!  
2. Goal: Increase the Flow. I asked that we minimize the unnecessary dependency somewhat so that each subsection can be launched benefiting the customers. This would mean we would have one newsletter without the interstitial video and one with the interstitial video so that the newsletter can launch sooner, benefiting the clients. Similarly, come up with recruitment emails to the long form video so that those long form video content would launch. Furthermore, agree on the minimally acceptable text on the three brand's independent landing pages as a call to action to the long form video content!  I call this approach "Let the birds fly" referring to each project component in the brand's program as a bird.

Voila! For the very first time, they allowed me to raise my observations in that meeting. They were all willing to amend the processes to ensure value is delivered. So, instead of complaining about the processes or the clients, I escalated the risks that are compromising their goals. I addressed the "What's in it for Them" on their own terms. 

Fast forward another month, after we successfully launched, I received a communication from the pharma's copy approval team (CAT) informing me that they have met internally based on some of my recommendations to institute such changes as part of any multi-component programs to minimize risks increasing flow and reducing waiting time (Name deidentified, personal communication, July 19, 2011). Now, that means success has doubled! Agility should be practiced even when no one uses any of the Agile recommended steps! 

I would say success was tripled because this change I proposed brought even the senior executives in my organization to work with me on how to structure the deals in sales not only to maximize deal size but also eliminate the structural dependencies in the agreements to optimize the program for incremental benefit delivery and recognize value faster! 

Personally, I would like to say the success was quadrupled because I was even promoted to be the manager of the Program Management Office that I had formed. 

As Gandhi said, "Be the agent of change that you would like to see in the world!" Thoughts?

Ignorance is not an excuse: Continuous Learning and Risk Management

In late 1989, I was doing a project as part of practical training required to complete my degree requirements for my Engineering degree. My project was on "Forward Error Correcting Codes" at Vikram Sarabai Space Center (VSCC).  The project required me to work with a small subset of errors arising due to the noise generated during shuttle noises and come up with codes that can make course correcting adjustments. Granted, I was working on a small simulation scenario. Well, my program didn't address about 10% of the scenario and I needed more time. My unit manager authorized an extension of a week when I have my program working. 

When I returned to the VSCC, I needed to get the entry card from the plant manager, who refused to give me the card without which I can't get to any facility. I had forgotten to turn in the card the previous time. When I mentioned that I didn't know I should return the card, he read the fine print on the card itself and said, "Ignorance is not an excuse!" Those words still ring in my ears as that was probably the best practical introduction to risk management in my life. Since then, I have done my best to read the details, understand as much as I can, and follow up when I don't understand. 

As I was heading the PMO, I asked about the risks that the project managers have identified for their projects. Even though some projects are simple cookie-cutter type of email campaigns, every assumption made on those projects is a risk. Working with a new client is a risk. Working on newer initiatives is a risk. Leveraging newer technologies, techniques, and tools is a risk. Therefore, in today's rapidly evolving world, the adage "ignorance is not an excuse" holds more weight than ever before. As individuals and professionals, we are constantly faced with new challenges, technologies, and potential risks that can impact our lives and work. It is our responsibility to stay informed and proactively seek knowledge to navigate these complexities effectively.

Continuous learning is no longer a luxury but a necessity. The risks we face, whether in cybersecurity, financial management, or environmental concerns, are constantly shifting and expanding. By committing to ongoing education and staying abreast of developments in our fields, we equip ourselves with the tools to identify and mitigate potential threats before they become critical issues.

Moreover, the modern workplace demands a more holistic approach to roles and responsibilities. Project managers are now expected to think like account managers (Think of the clients rather than focus on deliverable), understanding client needs and business implications. Developers must adopt the mindset of testers (Test Driven Development), anticipating potential issues and edge cases in their code. Similarly, development teams need to consider operational concerns, embracing DevOps principles for smoother deployments and maintenance. I see these trends towards the hybrid roles and cross-functional skills are applicable in my current organization to improve productivity. This is a powerful tool for comprehensive risk identification, analysis, and treatment. By understanding multiple perspectives, professionals can anticipate and address potential issues that might otherwise fall through the cracks of siloed thinking.

Ultimately, the pursuit of knowledge is a personal responsibility with collective benefits. By continuously expanding our understanding of potential risks, staying informed about best practices, and developing cross-functional skills, we not only protect ourselves but also contribute to a more resilient and informed society. In this context, ignorance is not just an inadequate excuse—it's a preventable liability that we all have the power and duty to address, both individually and as part of our professional teams.

The best way to address risks in products, projects, and programs and in our personal and professional lives is by continuous learning! Learning is a lifelong process and the more we learn the more we have the responsibility to teach others to learn. Learning therefore is also a leadership practice. Wouldn't you agree?

Leading Change: Remote Teams can collocate on the right ALM tools

When I began working at Physicians Interactive, there were many tools. One business entity used Jira for tracking tasks. Another business entity used OnTime. Both business teams used Mercury for tracking test cases and compiled defects on a project through email for tracking. In addition, the development team used manual tracking sheets, such as the ones seen for interdepartmental communication to track who is doing what and when things are required. The project management team used Microsoft Project to update their updates to predict when the project will launch. Some teams across these two business entities were spread geographically requiring duplication of these manual tracking sheets for development purposes!

When I started consulting for the company, I was not very happy. I felt that most of the time was spent updating manual tracking sheets, duplicating work through emails, and updating the project plans that was not used by anyone! When I talked to the infrastructure team that managed all the applications, I found that they had purchased the SpiraTeam ALM tool which no one used. When I probed for the reason for not using the ALM tool or their preference to be using their existing manual processes, the answer was something like “This is how it is done here!”

I didn’t want to take this answer and wanted to turn this process around. Using delay as a pseudo resource in the project schedule, I documented the amount of time spent on project that didn’t generate any value but cost money to the company (my hourly rate * the number of hours spent waiting!). Simultaneously, I tested SpiraTeam myself mapping the developmental and operational processes for the critical teams to the workflow capabilities within Spira. Then, I compiled the cost of licenses for the various tools. When I compiled all these findings for the senior leadership, the writing was clear! Why would we want to resist adopting the tool while wasting money paying consultants and the tool vendors, wasting time (note that time is money) duplicating efforts for remote teams and other teams that didn’t have the access to the tools due to licenses, while not generating the value for the company?

The leadership team and the managers of the business units were willing to adapt the ALM tool. We mapped the users, created the queue managers, created the workflow, adapted the phases, etc. Due to the cost of licensing and the overarching artefact support, requirements for business, technical, and compliance requirements, test case authoring and tracking of the test cases and defect management to requirements, defect triage process support, and tracking the definition of done through task management, SpiraTeam emerged as the winner. The continuous 'listening ears' of the Inflectra person for how the release management should work, the traceability to tasks, and potential to include risks sealed the deal on SpiraTeam because none of the other products had anyone willing to spend time. 

While we managed the risk register outside this system, the convergence of tools improved the "total cost of ownership" (TCO) and enhanced the "single source of truth" (SST). While the finance and business were happy with the former, the compliance and audit team were happy with the latter. As the head of PMO now, using Spira improved the transparency of work avoiding waiting time and improving value flow. Even the remote teams spread across the countries were able to collocate themselves on the ALM tool tracking their conversations through comments. Manual processes such as tracking sheets, compiling defects in Excel for email communication, and having standup meetings to discuss updates for other remote teams were avoided. As the saying goes, "We stopped starting and started finishing!"

It is not that people are unwilling to change. It is just that nobody cared enough to lead the change lobbying people through the change giving a platform for people to reason with change. Any change like this is not a one-person show! Multiple department heads weighed in on their concerns in the process but were willing to collaborate on a solution. Yes, there were some comfort zones with tools for certain members, but they were willing to see the opportunities ahead and recognize the shortcomings of the current tools. It took a village to see such an electronic tracking of requirements, test cases, tasks, and defects augmented by structured naming conventions to documents and file folders.

After one year of having this entire PMO running on SpiraTeam with hundreds of project launches, I am happy to see that we have improved transparency to our workflow to do more with less!

References

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

Dependency is a Risk to be Managed

Anyone in project management knows that dependency is a risk. When tasks are using the most common finish-to-start dependency, the delayed completion of predecessor task introduces a risk to the project. When resources are unavailable to start the tasks or their capacity is reduced to work on a project, their dependency on other project commitments poses a risk. Waiting time on processes, such as workflow approval, or not having a clear process, such as a lack of documented code review guidelines, introduces dependency on others. Technical architecture decisions requiring a dependency on other SMEs or dependency on training due to the lack of knowledge on the technology or tools adds risk. Organizational cultural considerations on budget approval, procurement considerations, or hiring processes are dependent on stakeholders for decision-making. 

So, as you can see, there are people, process, technical, and organizational dependencies either deliberately introduced (hard logic) or mandatorily included (hard logic) can be looked from internal and external considerations. The internal considerations may be within the team or within the company. As a result, we can come up with a table as below. Given below are some examples of dependencies that may be a risk.

How do you think this will work for your organization? Share your thoughts.

Godzilla Principle: Planning is Essential

I had a personal party and had invited a few friends to my house. As people assembled and the festivities began, I was focused on entertaining people. My son asked about his friend who was the son of one of our friends. It dawned on me to follow up that person. Unfortunately for him, he had a little car trouble enroute to our house. As soon as I told this to the group assembled, one of the people volunteered to drive and pick him up. During that chit chat that followed, a parent of the friend commented about how we missed out on the Godzilla principle. I have not heard that term before but didn't have time to follow up. The party mood carried on! 

Later the following week, I was attending a meeting group as part of Six Sigma discussions. As the head of PMO and as part of my continuous quest for learning, I took part in local discussions. Some were strangers and we discussed challenges with processes and other ideas. One of them discussed the principle of "Rule of 7". This is a principle that talks about consistent observations that are either increasing or decreasing within the upper and lower threshold levels indicating that a problem is about to happen. My inner voice started asking if anyone knew of this Godzilla principle. 

Lo and behold! It seems that it is in fact a principle that stands out for not monitoring certain activities responsibly and taking appropriate actions to address them. As the person said, "Don't let the problem grow to be a monster and destroy your project." In the context of the "Rule of 7," perhaps, this means that a series of 7 occurrences probably indicate that a larger problem is brewing warranting attention. It is also a principle that people seem to have used to identify the biggest contributing force to a planned delivery. I guess, this then also contributes to the Pareto principle of 80-20 rule! To me, this Godzilla principle also indicates how much we must apply careful proactive reasoning to look for things that could go wrong and build contingencies. 

Now, I am not too sure if this has anything to do with the Godzilla character that roamed the movies destroying anything in its way. I don't know if there is any connection to this character being so huge due to man-made experiments gone awry requiring us to think through the impact of what we do or do not do. However, I learned of a new Godzilla principle as another approach to inculcate preventive and corrective actions as part of risk management thinking. 

Have you heard of such a term? Have you heard any other such principles? Please share.

Essential Elements of a Project Binder

Late in December 2011, one of my good friends and coworker told me that I should start a blog. "You have so much to offer, and you should share it with others," he said. Now, having done my PhD with a dissertation on Leadership and Project Management, I know of the principles of servant leadership. I volunteered in many places to share my knowledge and mentored a few people too. But my friend's statement made me think. While there may be many others more qualified than me to share knowledge, if one person thought I have something to share with the world, why should I not? After all, I will never know who will benefit from what I share whether that is meaningful, relevant, and useful! 

Based on discussions with this friend, I started this first blog article on what makes up an essential project binder. Otherwise, elements of a good project plan which is beyond a Project Schedule! One has to incorporate additional thoughts depending upon the size and complexity of the project, visibility of the project in the company, and the nature of the industry. Nevertheless, the following 10 elements apply.

1. Project Charter (Typically 1-2 pages)
2. Scope Statement (Typically 1-2 sentences)
3. Assumptions (What is expected to be true) and Constraints (What are known to be true)
4. Risks
1. Types of Risk
2. Probability and Impact Scale
3. Risk Exposure Ranking
4. Contingency Reserve
5. Response Strategy
6. Treatment Plans for critical risks
5. High Level Requirements
1. List of Deliverables
2. Delivery Milestones
3. Funding Considerations
4. Approval Considerations
6. Project Plan
1. SOW or any related agreements
2. Stakeholders List
3. Resource List
4. Team Charter 
5. Conflict Management Considerations
6. Definition of Done
7. WBS (to the extent known with more clarity for the first few milestone)
8. Major (Funding Related) & Minor (Deliverable Focused) Milestones
9. Basis of Estimates (Cost and Schedule)
10. Approval considerations for change management
7. Communication
1. Management Communication
2. Team Communication
3. Progress Metrics Evaluation Cadence
4. Issues Log
8. Acceptance
1. Quality Definitions
2. Testing and Triage Considerations
3. Acceptance Criteria
9. Project Review
1. Incremental Lessons Learned (WoW Factors)
2. Final Lessons Learned (With Team, Management, and Client)
10. Recognition
1. Team Member Recognition 
2. Client Recognition

Hope this is a good start for anyone embarking on their project management journey! Let me know if I missed anything.