Phy-gital Roundtable: Breakfast Roundup from Germany and Netherlands

02 May '15 | Debjyoti Paul

German Shoppers: Meet Them in the Fast Lane to Phy-gital

15 January '15 | Ralf Reich

Shoppers Will Share Personal Information (But They Don’t Want to be “Friends”)

15 January '15 | Anil Venkat

Modernize or Perish: Property and Casualty Insurers and IT Solutions

14 January '15 | Manesh Rajendran

Benelux Reaches the Phy-gital Tipping Point: Omnichannel Readiness is Crucial

13 January '15 | Anil Gandharve

The New Omnichannel Dynamic: Finding Core Principles Across Industries

13 January '15 | Debjyoti Paul

Technology does not disrupt business – CIO day 2014 Roundup

02 December '14 | Anshuman Singh

Apple Pay – The Best Is Yet To Come

02 December '14 | Indy Sawhney

Digital transformation is a business transformation enabled by technology

01 December '14 | Amit Varma

3 Stages of FATCA Testing and Quality Assurance

06 October '14 | Raman Suprajarama

3 Reasons why Apple Pay could dominate the payments space

18 September '14 | Gaurav Johri

Beacon of Hope: Serving Growth and Customer Satisfaction

05 August '14 | Debjyoti Paul

The Dos and Don’ts of Emerging Technologies Like iBeacon

30 July '14 | Debjyoti Paul

What You Sold Us On – eCommerce Award Finalist Selections

17 July '14 | Anshuman Singh

3 Steps to Getting Started with Microsoft Azure Cloud Services

04 June '14 | Koushik Ramani

8 Steps to Building a Successful Self Service Portal

03 June '14 | Giridhar LV

Innovation outsourced – a myth or a mirage or a truth staring at us?

13 January '14 | Ramesh Hosahalli

What does a mobile user want?

03 January '14 | Gopikrishna Aravindan

Black Holes in Software Product Management

Posted on: 16 June '11

This blog is a continuation of my previous blog “Blind Spots in Project Management“. Thanks a lot Sai Ganesh Ramani and Naresh, for continually giving your points of views. In this blog, I am touching upon some of your comments on the earlier blog as well.

I had an opportunity to fly from Bangalore to Delhi on a business trip last month. In both these airports, the aero-bridge for boarding/un-boarding the passengers were not used. Is it because of Gate unavailability or aircraft (Airbus A320) type support for the bridges, I am not sure. But it is an inconvenience and shows poor planning or implementation in designing/running the airport. (When will we build an aerotropolis?)

Last month, thanks to iCMG organized “CXO Dinner Meet”, I had the pleasure of listening to John Zachman in person. Though some of the interesting points that he presented were in the context of the importance of Enterprise Architecture, at the micro level, those points are applicable to product or project management as well. His points were

  1. Anything that cannot be described cannot be understood/implemented/changed.
  2. Most of the time, professionals are focusing on short term “urgent” things compromising on the long term “important” ones (like Sai pointed out in my earlier blog).
  3. IT (Information Technology) is becoming a commodity day by day and it is better for companies to focus on their core competencies and build competitive advantage, and outsource IT operations. But obviously they should be knowledgeable on what has been outsourced and have the capability to track and monitor.
  4. The customer market is by one (customer)! Every customer that walks into a retail store is unique and a retailer who addresses those unique needs of each customer will be a big winner!

I happened to read the article “IT does not matter” by Nicholas Carr, which reiterated point #3 above. Though IT does not provide competitive advantage any more, it has become an operational necessity (like electricity) without which the business function will stop. (The competitive advantage can be brought in through specialized programs based on Analytics/BI etc. which are not operational initiatives though.) Depending on the success and adaptation of cloud computing technology/methodology, IT is going to be even more commoditized. Like I mentioned in my earlier blog “Cloud Computing – Been There, Done That!” the companies which can reach out to servicing the SME market might become a big success.

With all these in picture, the operational IT is better outsourced (I am not saying offshored!) to the vendors who are better at IT and business companies can concentrate on building their core competencies sharper.

This was reinforced with my personal experience of renewing my driving license at the Bangalore RTO. Even after doing a complete research on the internet and RTO website & taking help from the help desk person at RTO, I missed the photo shoot at RTO. Nobody informed me about this procedure and it was nowhere mentioned either. There is no complete instruction set available anywhere! To give the photograph, I had to drive back to RTO again another day. (On that day, while I was getting out of the car, I received an important call and with that distraction, got locked out of my car, which by the way happened for the first time in my 16 years of car driving experience. So, I had to go back to my house, get the duplicate key, get on to the car and go on!) In essence I had to apply for half-day leave, not to mention about the petrol/money/time wastage. If I had given the same work to an agent at the RTO for a petty amount, I would have been saved off all these hardships.

When there is not enough information readily available and when it is not our core competence, it is better to outsource the job to an agent/vendor. This experience again reinforces my blog “Travel Agencies are here to Stay“.

In this context, the success of a software product depends on the important points mentioned in my earlier blog and some more are given below. A software PM/DM’s role becomes much more important from a customer business perspective, since the responsibility has increased. As Naresh commented in my earlier blog, the software product management is a complex subject and the style/execution/approach varies from product to product and life cycle to life cycle.

The following blind spots can become black holes sucking project funding, either through rework, schedule/effort variance or the complete product objectives not met on time.

1.  Incorrect Estimation

Not employing the right estimation technique and right experienced technological/functional people can become a major issue in the software product delivery. The estimation could be far from reality (either positively or negatively) if the functional domain, requirements and technological landscape was not understood by the estimation team correctly.

For example, there are instances of reinventing the wheel for a product. In one instance of my experience, there was a requirement for an EDIFACT parser as part of the development. Construction of the same came to around 3 digit staff days whereas there was a tool available for the same in the market for a negligible price, with an integration effort of 10% of ground-up construction. It also saved all the rework/defects that could have come along with ground-up construction effort.

During estimation, the functional, technical and market knowledge helps in identifying the right tools which would help the project success.

2.  Understanding the Team and each member’s talents

Forming the right team in place and knowing each member’s talents/skills/knowledge is also critical for the success. Skills and Knowledge can be acquired through self learning, training and on-the-job experience. But talent cannot be acquired through any training.

(I am a fan of the book “First, break all the rules – what the World’s greatest Managers do Differently” by Marcus Buckingham. The concept is explained very well there. For example, a programmer will excel if he/she has got problem solving talent (where all the data required for solving is present) and a system analyst will excel if he/she has got formulation talent (where the analyst needs to think through all the scenarios).

But the very nature of IT industry operates in such a way that people have fast progression without having the opportunity to develop the talent required for the role. Being unaware of such mismatches of roles vs. talents, and not taking enough counter measures to normalize the impact, will have an adverse impact on software delivery.

3.  Lose control of Scope/Requirements

As a PM/DM, whether there is a financial impact or not, change of scope should be recognized (first, need capability to understand the change), well documented and all the stakeholders to be informed. Loose requirements/scope normally leads to most of the product failures. The PM’s ability in leading the team, keeping the stakeholders in constant communication and negotiations play a very important role here.

4.  Metrics, Tools, Processes and Reporting

Choosing the right list of Metrics for each of the engineering phase of the product development/maintenance, choosing the right tools and setting the right processes and life cycle will help avoid these black holes which drain the company’s budgeted funds. Each and every product and its stakeholders are different and choosing the right customized life cycle model (water fall, agile methodology, iterative etc.) and having the stakeholders engaged through reports will avoid major surprises.

Your comments are most welcome and we can learn from each other. Please let me know your views and see you again later.



Mindtree Blog Archives

Mindtree blog Archives are a collection of blogs by various authors who have independently contributed as thought leaders in the past. We may or may not be in a position to get the authors to respond to your comments.

  • Rohit P. Khare

    I previously worked as project manager for a key government organization. My experience is that the biggest black hole in any project management is not involving the lower employees while studying the requirements.

    The software team doesn’t become a part of the client’s organization. I did not mean physically but behaviorally.

    Most project managers tap the senior management of the client and prepare the software blueprint depending upon their feedback. The result is that when the final software is deployed, it is not able to satisfy most of the client needs.

    The most valuable input comes from the lower employees who actually deal with customers and use the core components of the software.


    • Romby

      Action reqruies knowledge, and now I can act!

  • Saiganesh Ramani

    Few comments from me:
    1. Estimation is always a black art. I have not seen any project in my life time that has predicted the correct number of effort days/months required – with 99% of the time seeing an overshoot of course. Software Engineering is just too fuzzy to make an accurate estimation. In general, other engineering activities have decent methodologies to estimate and we are still struggling in this area.
    2. With the global workforce being the norm, Managers have very hard time figuring out ways to understand individual talents. But I agree this is something that organizations should work on understanding for their own good.

    More comments later

  • Saiganesh Ramani

    3. Scope Creep
    It is always the things that are said in between the lines that trip us out. It is very hard to categorize hidden requirements as scope creep. One of the example that I faced with some of my earlier projects is that we had intense discussions with the customer on the requirements and UI interaction and we delivered everything both from a client and server functions, however the customer was expecting the same level of functionality in the Web UI at the same time and he has been seriously planning his deployment while we were seriously developing it in our app specific Rich Client UI. Very difficult to categorize this as a scope creep. (Your paraphrasing of Blind Spot suits this perfectly).
    Lesson learnt by me: Having an additional (serious) discussion about deployability of product at the concept phase really helps. It resolves a whole lot of unknowns and also grounds the architects and the development team firmly on reality.

  • Indy

    Please keep trhwonig these posts up they help tons.

  • product strategy

    Software product management discipline helps in managing software products from its beginning to support. It covers strategic issues of managing products including technical and business roadmapping, resource planning as well as strategic and tactical planning. In this qualitative study, we interviewed six organizations to understand how software product management is implemented in the organizations.