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