1. Comparison and Contrast of IT Project Management in IT Service industry versus the IT
product development industry
Hi fellow managers, today, I would like to write on the often discussed topic of the
approach to IT Project Management in the IT Service delivery versus IT Product
development industry. General (and rather inaccurate) inscriptions/presumptions center
around the IT Service delivery being less demanding as IT product industry to a 'different
work culture and ethos'. These might all be partly correct but they are definitely
analogous to the tale of 6 blindfolded men describing an elephant. Let us take a
sequential and gradual approach to examine each of these industries and the management
style. In certain large IT organizations, one might find both of these as separate
departments within the same company (like Microsoft, Oracle, IBM etc):
a. IT Service delivery/industry: The main factors and cornerstones of IT service delivery
within medium (1000 employee) to large (5,000+) organizations are as follows:
- Definition of Service: What is the IT service being offered? Is it coding support, fresh
application construction, maintenance, production support, database maintenance,
automation of programs etc?
- Definition of Customer: Who is the customer to whom the service is being offered? Is
he the end-customer to consume the information or is he going to process the information
and send it to another entity or company later?
- Definition of Service Parameters: How will the service be delivered - remotely,
automatically (via automated software/cloud), virtualized and the nature of service
(continual, annual, monthly, on-demand) etc.
- Nature of the Customer: Is it an internal customer (another dept.) or external (a
supplier/end-customer/vendor/individual)? These all need to be defined.
- Benchmarking of the Service: What are the benchmarks to ensure that the service is
meeting the agreed upon SLAs or parameters and passing on the benefits or value to the
end-user? Who will sign off on the service delivery and/or deliverables etc?
As you see above, in an IT service-oriented internal/external organization, it is necessary
for the IT project and program management to define things clearly, turn abstract
information into well-defined bodies of information and approach things gradually
instead of hastening to ensure proper service delivery and the appreciation of benefits by
its end-customer
b. IT product development industry: Contraventionally, the main factors and cornerstones
for IT product development are vastly different as we can see here:

2. - Definition of Target Customer Base: For any product to be developed, it is extremely
important for the product team to understand the Target Customer Base - who is the
customer, what kind of product are they building, how will it be utilized by end-
customer, what is the business problem that the product will address? This all information
is necessary to be part of the 'Requirement gathering and Requirement definition process'
while building the said product.
- Definition of Team structure and SDLC selection: Once the requirements have been
made granular, the product team needs to define a Team structure and assess and select
an SDLC for the product. This could be either Iterative, Waterfall/Cascade or Agile type
of SDLC. Each of the SDLC type is suited to individual types of products and their
lifecycle. For example, Waterfall has been found to be more effective when requirements
are clearly written and frozen and teams well defined. On the other hand, Iterative SDLC
is good for small-sized products requiring frequent builds and shorter lifecycles. Agile,
the newest kid on the block, is good for small-medium sized projects with high energy
teams where team structure and requirements are not well defined and business wants to
get something out the door at regular intervals.
- Utilization of the Product and its Lifecycle: Who will utilize the product, how, in what
configuration and operating system, how many users will be using it? What will be the
overall lifecycle of the product, how much warranty, what will happen after the lifecycle
of the product expires? Will there be a new version or will the same product be
improvised upon? These questions need to be answered, atleast thought upon while the
product is being built.
- General Management Structure in the Product Organization: The product team needs to
add a management structure above their organization to be able to deliver and sell the
product as well as interact with the end-customer on the product.
- Servicing the product: Who will service the product - internally trained users, a
customer help desk, an outside organization, or clients creating their own team to
supporting the product's users? This also requires creating support blocks for the Product
support team (SLA agreements, Maintenance and Downtime windows, on-call teams.
production Level 1 and 2 support, issue resolution structure etc)
- Creating an Ecosystem: In the world of ecosystems, no single product can survive the
test of time without a solid IT ecosystem and supporting applications like Help Manuals,
White Papers, User Forums, Product Wiki and other integrated, interacting applications
to provide the user a complete ecosystem to work in, not just a standalone product by
itself. Examples are MS office, MS access and SQL server, Oracle suite of DB products,
IBM's Rational suite of products, LAMP Stack in open source apps etc
So, as you can see, the IT Product Development Organization necessitates a completely
different approach for the IT Management to 'define, envision and structurize' intangible
information like requirements, user experiences, business rules, artifacts and user wants
into a 'Usable, Reliable and Valuable IT product' which not only solves the immediate

3. business issue but also provides interconnectivity to related applications and creates an
ecosystem so that the user can work in the IT ecosystem for a complete user experience
and increased organizational productivity and output.