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.