Importance of Innovation

In a hard-hitting article in today's (3rd July 2012) issue of The Economic Times, former NASSCOM president Kiran Karnik makes a strong case for promoting innovation among Indians. Karnik says that the three 'i's of innovation, invention and ideas are essential for any individual, organization, society or country to gain a decisive edge in today's competitive, globalized world. He bemoans the fact that India today is dominated by political elements that seek homogenization at the cost of the immense diversity that has traditionally defined our country, and which along with adversity is the prime driver of innovation. Other roadblocks for innovation in today's India are censorship, moral policing and the feudalistic mindset symbolized by the beacons on VIP cars

What Karnik says about India as a country is also valid for organizations. Every company tends to have dictatorial leaders or cliques that seek to impose a particular culture on the entire organization, while muzzling any independent voices in the name of hierarchy and respect for authority. What they don't realize is that such lack of diversity ultimately results in total absence of innovation, leaving them with a complacent workforce that is happy to maintain the status quo, without ever thinking out of the box or coming up with more efficient and effective solutions. Also, while many companies have started allocating a significant proportion of their budget to draw out new ideas from their staff, they don't usually put in as much time and effort to develop those ideas to fruition. A good manager has to not only inculcate the spirit of innovation in his employees but also nurture it and ensure that it produces tangible results that add value to the entire organization

Managing Scope Creep

However well defined your SOW document, however detailed your SRS document, some amount of scope creep is inevitable during the development phase of a software project. When a customer previews the system that is being developed, they are bound to come up with new ideas on how a particular module, report or web page should look. Of course, a strong project manager or project sponsor would try and negotiate a corresponding increase in either the budget or schedule or both, in which case, the increase in scope would be treated as an acceptable change request. But if the customer is a VIP client, or if your initial project documents were not specific enough about the scope, you end up having to accept the changes and work them into your schedule and budget. Your best best in such a case is to try and minimize the impact of the scope creep, especially on the confidence of the development team. You could do this by asking the customer to prioritize the changes and ask your team to target only the high priority items at first. At the same time, you would have to negotiate with the customer and set reasonable and realistic expectations about the timely completion of the changes. Most customers would be willing to concede some extra days for low priority changes, beyond the implementation date of the project. Of course, keeping the team engaged for longer on one project could affect the schedules of other future engagements. But, as a project manager, you would still end up having made the best of a bad situation

Virtual Employees

An article in yesterday's (1st June 2012) issue of The Economic Times exhorts organizations to find ways to connect with their virtual employees. The author Abhijit Bhaduri, the chief learning officer at Wipro, stresses that virtual workers do not only mean employees working in another country or city and in fact could be people working in an office just across the road. The plight of such employees typify the saying "out of sight, out of mind". There is no emotional connect with the leader, the team and even the organization. This results in a major drop in employee engagement, which may ultimately result in higher attrition levels

Having seen this first-hand in my last company, I cannot help but agree with Mr. Bhaduri. The top bosses of our Business Unit were based in Bangalore and rarely visited Mumbai. Obviously they would interact more often with Bangalore team members, in the hallways and cafeterias, than with employees at other centers. As a result, even the most minor achievements of Bangalore staff got recognized at the highest levels in the organization, whereas their Mumbai counterparts would slave away all year only to receive "average" ratings and infrequent promotions. This resulted in many Mumbai team members attempting to leave the BU, and when that did not work out due to headcount politics, opting to leave the organization itself

The lesson here for all leaders having virtual employees is to try and personally interact with them as often as possible, even if they work at multiple offices across various locations. Making employees feel wanted and appreciated is the best way to keep them engaged. Bhaduri reminds organizations to use technology, process guidelines and informal rewards to ensure that virtual workers have what he calls "a share of mind, voice and wallet"

Long Distance Project Management

Managing an offshore project from an onshore (or near-shore location) is always a challenge. Though the project manager has the advantage of being close to the client, which is great for requirements gathering and later for UAT support, he/she could struggle to make the remote team stick to the schedule. Not only do you as a PM have no control over attendance and timings, you cannot stop the team leads or coordinators from making minor changes to your project plan as per their own judgement. If you allow them a free hand, you run the risk of losing control over the project. But if you complain or interfere too often, you are seen as playing power games and trying to micromanage. So you need to constantly walk a tightrope between being a dictator and being totally hands-off, while ensuring that the offshore team completes the project on schedule, at (or better still slightly below) budget and most importantly, to the satisfaction of the client

Project Documents - SRS

To continue the discussion from the previous post, the "high-level" requirements stated in the SOW are further elaborated in the System Requirements Specification, also known as the SRS document (or SyRS document, since the first acronym is sometimes interpreted as Software Requirements Specification). This document explains the business requirements in a more technical language, though without resorting to geek-speak, making it an ideal reference point both for the client and the development team

There is no fixed template as such for an SRS document, since the size and complexity of a project would determine the amount of information needed and hence the order in which it is arranged. For simple software development projects, this is the template I like to follow:

1  Introduction

2  High Level Scope

 2.1  Included In Project Scope

 2.2  Excluded From Project Scope

3  Overall Requirements Description

 3.1  System Overview Diagram

 3.2  Functional Requirements Specification

  3.2.1  Use Case 1: <transaction 1>

  3.2.2  Use Case 2: <transaction 2>

  3.2.3  Use Case 3: <transaction 3>

  3.2.4  Use Case 4: Master Data Entry

  3.2.5  Use Case 5: Legacy Data Entry

  3.2.6  Use Case 6: Reports

 3.3  Forms Overview

  3.3.1  Master Data Entry Forms

  3.3.2  Transactional Data Entry Forms

 3.4  Reports Overview

 3.5  High Level Database Design

4  Glossary Of Terms

5  Approvals

The Glossary or Definitions section is optional but good to have, as it explains business-specific terms to the development team and coding-specific terms to the client. All the other sections are essential since they establish exactly what the development team needs to deliver in order to meet the client's business requirements and thus make the project successful

Project Documents - SOW

Wikipedia defines the Statement Of Work (SOW) as "a formal document that captures and defines the work activities, deliverables, and timeline a vendor must execute in performance of specified work for a client". However, this definition misses out a very crucial phrase - "high-level"

An SOW is usually signed at the beginning of a project, when the IT vendor does not have a clear idea of the client's requirements, beyond what their Sales team has captured. And since most IT Sales folks are non-technical, what they state in the SOW are purely business requirements

When these get translated into technical requirements, we may end up with a completely different picture of the task complexity and practical timeline. However, having already signed off on an SOW with ambigously worded requirements, the IT vendor is unable to dispute any scope creep

Therefore an SOW needs to clearly state that the deliverables and timeline mentioned are at a high-level and subject to change during the system analysis & design phase. Ambiguous requirements should be highlighted as such, so that the client cannot interpret them to suit their own interest

Thus an SOW is an agreement to start a project, comprising of some high-level requirements, and to complete it by providing some high-level deliverables in some high-level timeline. The elaboration of these should be left to another project management document, namely the SRS document

The Three Mistakes of Nokia's (OS) Life

Last week, Samsung officially ovetook Nokia as the world's leading handset manufacturer. Though this was foreseen many months back, it is still hard to believe that the company that was an undisputed market leader across the mobile phone space just a few years ago has slipped so badly. The very economy of Finland, Nokia's birthplace, is at risk due to this fall from grace

It is easy to attribute Nokia's downfall to the quality of the competition (Samsung's Galaxy series of Android phones and tablets have won over Nokia users) or argue that their rivals moved the goalposts (Apple's iPhone revolutionized the smarphone business and knocked the wind from Nokia's sails, pun intended). But the fact is that Nokia had enough resources available, both in terms of technology and finances, to counter the iPhone/Android onslaught and hold on to their market leadership position. It was sheer lack of focus on their part, and the inability to convert brilliant ideas into best-selling products, that cost Nokia their crown. Here's a look at some of the occasions when Nokia missed the bus, at least as far as mobile Operating Systems are concerned:

1. Maemo = The OS based on Debian GNU/Linux, introduced in 2005, won praise from geeks but was never developed further

2. Meego = The partnership with Intel on this Linux-based OS, which was cancelled in 2011 in favour of Tizen, was a non-starter

3. Symbian = Even as Nokia's flagship OS showed signs of changing with the times (Belle), it was replaced by Windows Phone

Other than the Windows Phone 8, which is anyway not expected to be a game-changer, Nokia is now said to be betting on a successor to Meego called the Meltemi. This OS will potentially replace both the Symbian smartphone OS and the S40 feature phone OS. Meltemi is the Greek name for a summer wind that blows across the Aegean Sea. Will this be another OS mistake by Nokia, or will the Meltemi bring winds of change that will sweep away rivals like iOS and Android from the mobile phone market? Only time will tell