Lean practices aim for productive and smarter ways of working (although not always the two go along together), so it’s a no-brainer that an efficient use of tools plays a crucial role in targeting a lean operational model.
The toolset used across an organisation can be quite diverse and if the organisation has been in the past subject to M&A, then it is likely that different working groups, once part of different companies and now collaborating in developing and delivering products and services, keep using their legacy tools with cases of overlapping functionality.
The following is a list of applications and services that was used in organisation that’d grown to be a global player after a few mergers and acquisitions in the space of five years; (DISCLAIMER) this list is not an indication of my personal preferences in each functional category, but only a reflection of what was in use at the time.
- (Atlassian) CONFLUENCE, wiki area, corporate repository and customer-facing reports
- (Atlassian) JIRA, development and support tracking with customer-facing dashboards
- (CA Technologies) RALLY, development and delivery management
- (Planview) INNOTAS, project portfolio management and time sheets reporting
- DELTEK, time tracking & reporting, expense and project accounting
- (Atlassian) BAMBOO, continuous integration and deployment
- (Atlassian) BITBUCKET, code management for Git
- (Sonatype) NEXUS, software build supply chain
- (Apache SF) SUBVERSION, software versioning and revision control system
- (Gurock) TESTRAIL, web-based test case management
- MOODLE, Learning Management System
- SALESFORCE.com, Customer Relationship Management
- (Microsoft) SKYPE, communication & collaboration
- (Microsoft) SKYPE FOR BUSINESS, communication & collaboration
- SLACK, collaboration tool specific for development and delivery teams
Going through the list I can highlight the overlaps across Confluence and Jira in terms of providing customers with project reporting and dashboards, the use of Rally and Jira when managing delivery of product suites from two divisions of the same organisation, or having two different tools being used to practically manage time entry on projects (Innotas and Deltek); instead I’ll focus the attention on the last three items of the list since they are very relevant to any Communication Management Strategy that should be in place, especially for those organisations heavily relying on work produced by geographically dispersed teams: Skype + Skype for Business + Slack.
To start with, Skype was used by a specific working group which got incorporated as the result of a recent acquisition; it had been selected years earlier as their primary communication and collaboration tool when they were still an independent company and reasonably (I would say) in the absence of a new directive stating otherwise, they simply kept on using it.
Skype for Business was instead used by the leading company’s workforce and since being part of the Office suite it was selected to allow communications across teams located in different regions (US, EMEA, APJ) as well as for cross-functional engagement and meetings (e.g. Engineering, Finance, R&D, HR).
Slack was rolled out in more recent times to provide a dedicated collaboration tool with instant messaging focused on exchange of technical info among team members involved in development and delivery-related tasks.
It is easy to predict how this kind of fragmentation can have an impact on seamless communication and collaboration across the organisation.
Whilst it is important to carefully support operational transitions in the event of M&A and allow working groups to be progressively embedded into a consolidated environment by also allowing short-term retention of legacy working practices and tools, it is also true that there must be a strategy in place for near/medium-term consolidation, since with the emphasis on productive collaboration and team work across geographically dispersed teams, the last thing you want in your day-to-day operations is a fragmented ecosystem of tools that may very likely create duplication of functionality, additional licensing costs and more importantly contribute to the creation of collaboration and communication silos.
Unless there are some very specific requirements to justify the existence and use of different tools for similar (if not same) purposes, and I can’t personally think of any of these scenarios, a Lean Tooling approach should ideally pursue the adoption of a single working tool per functional area.
Considering the initial status-quo and after reviewing the toolset in a collaborative manner, the target state is set to ensure alignment with a “lean” Target Operating Model (TOM): 30% reduction of tools and services in use …
- (Atlassian) CONFLUENCE, wiki area and corporate repository for internal use
- (Atlassian) JIRA, development and support tracking with customer-facing reports/dashboards
- (Planview) INNOTAS, project portfolio management, time sheets management and internal reporting
- (Atlassian) BAMBOO, continuous integration and deployment
- (Sonatype) NEXUS, software build supply chain
- (Apache SF) SUBVERSION, software versioning and revision control system
- (Gurock) TESTRAIL, web-based test case management
- MOODLE, Learning Management System
- SALESFORCE.com, Customer Relationship Management
- (Microsoft) SKYPE FOR BUSINESS, enterprise-wide communication & collaboration tool
Assumptions for this rationalisation effort:
- Consultation/Survey across representative groups currently using each of the tools under review and feedback consolidation for prioritising retention of each – e.g. Must / Should / Could / Won’t keep.
- Planning and execution of on-boarding activities for team members subject to face changes in their working tools and services (web-based-training and/or ILT).
- De-prioritise the introduction of new tools to prioritise instead the use of the existing set to minimise operational change and training support.
Thought process for executing this consolidation:
Confluence used exclusively for managing the organisation’s internal knowledge base, repositories for policies and procedures (for example in relation to methodologies or ISO-9001/27001 guidelines) and templates, therefore removing from its scope the provisioning of customer-facing content.
Jira expands its scope and operational reach to become the one application that is used to follow each phase of development and delivery life-cycle, and it is made the primary source of customer-facing reports and dashboards for status update sharing on tasks and/or issue tracking.
Innotas becomes the one-stop-shop for project time entry and reporting information relevant to internal/external billing.
Management of the various operational aspects of CI/CD by using Bamboo, Nexus, Subversion and Testrail; from a holistic DevOps standpoint, we also include Jira into the equation.
Moodle and Salesforce are kept given their instrumental relevance to LMS and CRM related work.
Out of the three similar tools previously used for communication and collaboration, we phase out two and just keep Skype for Business also given its integration with the Office suite and more specifically with Outlook; this way we also enable non-technical team members to occasionally participate at technical sessions when they deemed this as necessary and without having to use a different tool just for the occasion; ultimately Slack, although cleverly structured to engage users through chat rooms (called channels), didn’t bring the additional value to justify its continued presence in the corporate toolset.
In terms of Communications Management, by funnelling instant messaging, audio/video calls and the ability to quickly file-sharing content across individuals and teams, we stimulate focus, undoubtedly an essential ingredient for qualitative communications also proven by years of experience on the field where having less choice is often better than having too much choice.