A WFH (Work From Home) Checklist

How to work from home effectively? How to interact with team? How to give presentations to customers online? How can organizations rebuild or reorient themselves into the new culture?

This is not especially easy given the fact it is new to most people. Many of them might have been used to working for a few hours from home. Now, WFH means conceptually redesigning a part of your home as the workplace. A designated work place should be sacro-sanct. At the same time, one must not be immune to the fact the one is surrounded by their loved ones and a certain amount of distraction is bound to happen.

Here is a brief 3-point checklist for the organizations and the employees.

For the organizations:

1. Set up the base well i.e. provide for the best-in-class infrastructure

• A stable, high-speed internet connection is a must. Reimburse the employees. The employees are saving the organizations a lot of money by being at home. This is the least they should get in order to discharge the responsibilities.
• Devices (Desktop / Laptop) loaded with current software / Anti-virus
• Consistent collaboration tools for performing meetings, audio / video sessions with colleagues and / or customers
• Ensure security compliance / VPN availability / awareness training. Lot of security restrictions may be rendered irrelevant at home. Be mindful of that and inculcate standards

2. Publish business etiquette

• Agree on working hours calendar (on a weekly or monthly basis)
• Specify an “All-hands-available” window wherein every employee is expected to be online and can be accessed
• Consistent calendar sharing with required permissions
• Communicate constantly and consistently

3. Establish new support and care mechanisms

• Host virtual get-togethers
• Designate fun time / fun zone
• Celebrate WINS
• Bring life to festivals instead of a token “Wish you all…” and strengthen family bonding
• Provide support mechanisms to reach out in case mental ill-health

For the employees:

1. Set up a “Chinese Wall” between household and office work

• Some people designate a special area, inside the house, towards this purpose. This is a NO GO for other members. I have heard of people, dressed up in office wear, working from such area. This may not be feasible for everyone. It is important to designate a section (whether it is barred for others or not) and follow working protocol.
• Use a good quality ear phones / ear plugs / noise cancelling equipment.
• Adopt good ergonomic practices. This can include working whilst standing, moving around every hour, taking breaks etc.
• Learn to switch off and resist the tendency to be available 24*7 online. WFH doesn’t mean that you are expected to be available all the time. It also doesn’t mean that you can prioritize other things over office work.

·

2. Working effectively

• You should master the online ways of working, online meetings for effective work management. For example, one doesn’t have to use the phone all the time. Tools like MS Teams, Lync etc. provide opportunities for chatting.
• Ensure you understand the audio / video bridge details / other collaboration tools.
• It is not wise to do back-to-back meetings. Have your heard of people remarking that their entire days were taken up by meetings? It is not warranted and reflects inefficiency.
• To make meetings more effective, be clear with the purpose, pre-requisites and decision criteria. If someone comes ill-prepared and takes up huge time of everyone, it would be more prudent to reschedule the meetings.
• Use meeting recording function and notes function to share the minutes. It saves time by sending documents.
• Break the project into smaller chunks where appropriate.

3. Be human

• Show empathy, concern and understanding for your team members / colleagues.
• Be magnanimous when required and give freedom to manage their internal schedules subject to an overarching and agreed protocol.
• “Look” at your team members; get into video calls at least weekly.
• Understand their issues and work with them to solve 

As I had explained in my earlier blog post, companies have discovered a golden goose in WFH. It is better to apply our mind, instill some disciplined process and get used to the new ways of working.

Good luck…

Why does the business love Agile development?

Agile continues to be the preferred way of delivering business outcomes. Still organizations use waterfall techniques especially to the system of records. But it is agile that is becoming de rigeur for system of innovation and differentiation. Agile’s willingness to fail is the primary reason that endears it to the business.

I have been involved with more and more teams, especially in Europe. There are some very clear observations that are quite evident.

1. The mentality and emotion quotient surrounding a waterfall project team is still based on avoidance of risk. Of course, they do fill up the RAID log as it is commonly known. Documentation trumps up all other requirements.

   

   Agile Model in action

2. A pre-mature optimization happens in the delivery of such waterfall projects. Many factors contribute to it. One is the time lag behind the business requirements and delivery when everything changes around you in a faster manner. Second, the freezing of architecture and design without understanding some of the future-changes start pushing the projects into a tight corner.
3. Integration happens at the last and that’s where new but significant risks start to emerge as the project deals with other adjacencies.
4. Agile embraces risks and that’s what makes it adopt a different approach. The team starts in a humble manner and learn as they progress. Early and constant feedback changes the games.
5. With each sprint / release, integration happens. The product may be incomplete but it is brutally subjected to feedback and criticism. In general, the right behaviour, in agile teams, doesn’t make them nice and avoid negative feedback. The old adage “Silence is golden” doesn’t work.
6. As the teams, in waterfall, are split into smaller units for tighter control and delivery, the risks due to dependencies (known or unknown) rise faster. Michael Nygard says in Architecture without an end state “The problem with dependencies is that you can’t depend on them.”
7. Waterfall assumes the leader is quite capable and prone to enforcing a herd mentality. This works well to avoid a difficult terrain but not when the business is waiting to expand. In agile, the management trusts the teams to find their own way. This is not to was off one’s hands completely. After spending time to help the teams understand the big picture, trust the team to negotiate further. Equipping and empowering culture are important.
8. Recognizing that change is quite frequent, it is better to work on what we know latest instead of applying an artificial freeze. Agile teams remain flexible.
9. Team happiness becomes critical in agile teams. Continue to measure it.
10.  Agile teams indulge in such planning where more minds are put to work. Instead of waiting for someone to solve their problems, they are encouraged to find their own. The team, typically, rises to the challenges and comes with measures.

Not all parts of IT need to become fully agile for the sake of it.  But, the entire IT, as a coherent entity, needs to be agile o rnimble enough to the changing business. Where it makes sense and where IT remains a blocker to realizing business outcomes are those areas that should embrace this culture. 

Finally, a word of caution. Do not brand agile with no-process or free-for-all approach. It is where you lay the stress that becomes different. Projects in agile mode are also supported by quality and rigorous document and associated metrics. Informality should not be confused with indiscipline.

Is your CIO funding projects or business capabilities?

Context

Earlier, the CIOs tended to organize their teams and functions around specific projects. Wherever possible, consolidation was touted as the panacea! The seemingly good candidate is RTB (Run The Business) function that typically “Keep the lights on.” Support, both application and infrastructure, falls into this category.

As the rest of the units start aligning themselves to operate nimbly in an agile and digital world, what happened to the IT organization? Many CIOs have simply reorganized them using fancy terms but essentially retaining the same flavour. Ask them about the IT budget. They will talk about RUN and CHANGE. Drill them into more detail, for example the cost of introducing a new product and see their reaction!

In this blog, I share the experiences of working with CIOs and IT organizations around two important aspects.

• How to look at the IT budget and get answers quickly?
• How to align and develop an operating model?

Let’s understand the changing paradigms to the meaning of IT as organizations go digital and embrace new technologies:

Diagram #1: Emerging interpretation of IT in the digital context

In short, business strategy automatically becomes IT strategy. It is no longer possible for CIOs to emerge victorious when the entire business is going southwards! The CIOs are in the thick of things.

Funding Model

Diagram #2: IT Funding by Portfolio

Typically, the CIOs look at the funding by any of the three categories:

1. Type of focus - RTB (Run the Business), CTB (Change the Business) and Grow (Linked to Business Growth)
2. Budget (Cost of personnel, license, hardware, storage etc.)



Diagram #3: IT Funding by Budget

3. Financial accounting sense (Capex / Opex)

Diagram #4: IT Funding by Accounting

These types of funding keep the technological interdependencies and the business led IT aspects deeply hidden. The real cost drivers become virtually impossible to find quickly. In a way, this explains all the IT costs but presents an incomplete view. This may lead to investment silos and/or duplicates. The flexibility needed to understand digital investment is not the hallmark of these methods. Moreover, justifying the legacy refresh takes inordinate time.

Diagram #5: Allocation of IT Budget

Instead, allocate the IT budget by product line. For this, work with business to understand the strategic / relative importance of the product lines annually. Empower the PLMs (Product Line Managers) with the discretion to allocate funds to maintenance, technology refresh, innovation etc. They should have the wherewithal to reallocate the funding as priorities change.

In the diagram #6 below, an illustration is given. The key focus area is to build new business capabilities and ensure the business strategy is not impeded by IT. 

• New business capabilities (BC) are financed by respective business area budgets. Examples can be subscription based services like SaaS or getting third party services.
• New business capabilities are funded by IT to the extent of technology implementation or major changes/enhancements.
• Then comes the "Maintain to Operate" layer that focuses on licenses, upgrades, hardware/software maintenance, staffing etc.



Diagram #6: Shifting Budget Patterns



• Finally the digital foundation layer that addresses cloud / building new platforms etc. This directly mitigates operational risk.

As can be seen, the key differences to this type of approach are:

• Part of erstwhile IT budget for funding new products or building new capabilities is shifted to the respective business unit or area.
• Business area is the owner of the budget for introducing new capabilities.
• The funding that is required for digital foundation is separate from maintenance.
• The linkage of technology to the business capability is clear.

What comes out clearly is that enterprise wide view of technology spending covering business-led IT. This view complements the traditional views to gain quick insight into cost of transforming the landscape, cost of sustenance of new capabilities as well as introduction of newer ones. As the technology funding is clearly aligned to business, the ability of IT to influence and respond increases.

Operating Model

Let's start with what we aspects we should expect from the IT operating model.

• Faster time to market
• Greater business integration
• Flexible ways of working
• Improved customer experience

For this, we need to shift the mindset from projects to products. What are the differences?

Diagram #7: Redesigned Target Operating Model

How do we factor them in the operating model?

• Diagrams 7 and 8 give an overview of how to visualize these changes in the model and consequently the organization of the teams.
• Choose products or business capabilities over projects.
• Each capability is a vertical tower that comprises all IT operations pertaining to it. RTB and CTB work will come under this.
• The product line manager is empowered to organize his teams, allocate budget and change funding.
• These operations are done on the product lines in an agile / DevOps / CI manner.
• Everything cannot operate in a vertical stack. IT has to spot scaling / efficiency opportunities wherever possible. What is not common to each capability but to the entire organization is (1) the building blocks of application and (2) Cloud based scalable infrastructure. These may include shared applications, shared ERP, shared platforms, shared BI and shared data centre etc.

Diagram #8: Team Organization

Conclusion

It makes immense sense to appreciate the paradigm changes in the way IT is viewed and linked to the business. This should logically flow into the way the IT teams are structured and funded. 

What are the advantages of reorganizing the IT along these lines?

• Business knows easily the respective IT to discuss/contact.
• As the IT services each business capability, the skill sets / knowledge of understanding of the business grows within that unit. This means informed resources that have the ability to respond to changes.
• IT supports the business more efficiently in terms of understanding the cost components and come up with answers to question like – what will be the time taken / savings in IT if a product line is killed? what will be the incremental cost of introducing a new product in a particular market? Etc.
• The IT landscape becomes less complex and easier to understand/operate.
• The portfolio metrics, at each capability level, make direct sense to the business head as well as the CIO.

On a lighter note: If a CIO's lingo becomes as close to the business and everyone understands the CIO's response in the first instance itself without seeking further clarifications, latch on to that CIO for God's sake!

Which agile model is right for you? What are the solution considerations?

Choosing the right type of agile model is of paramount importance. Enterprises are experimenting with Scrum Kanban, XP, Spotify etc. Looking at the user interaction and rate of change as two parameters, we can make use a specific approach. The following diagram gives one such idea.

In the table below, the considerations of application type, type of work, type of team, volatility etc. determine the applicability of different methodology.

Parameter	Description
Application Type	Strategic Maintain Run to Retire PoC
Volatility Type	High, Medium, Low
Work Type	Large/Medium enhancement Maintenance/Small enhancement Migration Large platform based Innovation
Variability Type	Small, Medium, Large
Team Type	Independent Frequent collaboration High collaboration
System Type	Stand-alone/Small Medium complex/Medium dependencies Highly complex/Multi-dependencies

Based on the above, we can construct a table that shows the usage and applicability of various models.

Parameter	Scrum + XP	Scrum	Kanban	Waterfall
Application Type	PoC	Strategic	Maintain Run to Retire	Maintain Run to Retire
Work Type	Innovation Platform	Large/Medium enhancements	Small changes	Maintenance Migration
Team Type	High collaboration Frequent feedback	High collaboration Frequent feedback	Independent	Independent
Volatility Type	High	Medium	Low	Medium/Low
Variability Type	Large	Medium	Small	Medium/Small
System Type	Large/Complex	Medium complex	Small / Stand-alone	Medium complex/Medium dependencies

What are the factors to be considered in designing the solution and commercials?

When working with a customer's IT organization that is in some form of agile, the solutions team need to consider the following factors and ensure their impact on delivery as well as commercials is understood.

Area	Considerations	Impacting
Transition	·           Current level of agile maturity across business units (Each unit can operate in a different level) ·           Current offshoring maturity ·           Usage of distributed agile ·           Consider various scenarios like: o   Waterfall to Agile o   Agile to Agile.	·           Knowledge absorption: Include pair programming and architectural runway (Existing code, hardware components and software functionality that technically enable near term business features) ·           Replication: Sprint based execution ·           Boot camp duration and costs (focus on Agile foundation, Agile Associate, Scaled Agile. behaviour aspect - People mind set, culture ·           open-up and express their view) ·           Include time and effort for doing agile assessment of the in-scope portfolio ·           Onshore ratio ·           Timeline
Steady State	·           Agile maturity of different business units ·           Level of life cycle management and DevOps tools usage ·           Type of full stack engineers required ·           Availability of roles like PO, Agile coach, Scrum master with the customer ·           Time proposed for transformation ·           Quantum of work ·           Current effective tools usage ·           Usage of DevOps ·           Current mapping of resource levels	·           Operating Model ·           Evolution of ToM across time line ·           Squad size ·           Release cycle ·           Onshore ratio across months/years as the customer moves up on the maturity curve ·           Type of resources and their distribution ·           Productivity % resulting from people, process and tools
Commercials	·           Physical Infrastructure ·           Connectivity requirement considering more online interactions / meetings ·           Typical squad size per ODC (there could be many special requirements per squad)	·           # Travels could be more as compared to a traditional model ·           Special infrastructure (meeting rooms, furniture, boards, interactive rooms etc.)  costs ·           Special equipment like monitor (big size, two monitors per person) ·           Additional tools/license ILF (initial License Fee) and RLF (Recurring License Fee) ·           Cost of baselining the resources of the customer and plotting them against standard models like SFIA or Dreyfus model ·           Recruiting costs (cost of running hackathon) ·           Cost of hosting customer periodically ·           Cost of building Academy ·           Cost of configuration/customization of existing tools, frameworks and accelerators ·           Training / Upskilling costs covering the initial training required to make the resources more engagement ready as well as upskilling as they move the Dreyfus cycle. The traditional training materials will not do.