1. Hands-­‐on
or
Hands-­‐off:
Which
approach
suits
IT
business
heads
Have you come across situations where business heads in software
organizations
• Are uncomfortable in facing the development team. As a result, they don’t mingle
with the teams easily and use authority of their position to demand results?
• Are uncomfortable talking to customers about any technicalities of the project and
restrict themselves to discussing commercials?
• Are found inadequate to take proactive measures when software delivery results
are not up to the expectations?
Well, the above scenario is not too uncommon and there are many reasons for it.
A business head in an IT organization can get into that position from a variety of
career paths such as finance, HR and sales. Not all of them would have passed
through the mill of end-to-end project delivery to understand the nitty-gritties of
software delivery. And apparently many of them don’t need this understanding for
their day-to-day functioning as their typical job involves meeting customers,
building relationships, discussing commercials and closing the deals while
delivery is taken care of by project managers. In summary, many business heads
who get into that position laterally don't have background in software delivery and
don't need it either for their day-to-day functioning in business matters but face
certain limitations while dealing with delivery. Therefore, the question that arises
is whether this hands-off approach is just fine or the business heads have to do
something to become hands-on? In other words, do business heads need a
certain level of awareness about software project management? What do they
lose if they don’t have that awareness and what do they gain if they develop that
awareness? As we will examine in this article, business heads stand to gain
tremendously if they develop a basic level of skills in project management and
there are 3 main reasons for doing so. In order to understand the 3 reasons, we
have to first make clear the interrelation between software delivery results and
business results at a parametric level.
Impact of software delivery on business results
While it is common knowledge that a high quality software delivery can lead to
better business results, what is not evident is how it happens. Skill set of project
managers and processes are two key areas of delivery excellence. Process and
its skillful application result in improved delivery metrics. And some of these
metrics directly translate into business results including topline and bottom line
growth as shown in the diagram.

2.
The range of skills and process areas in software delivery is quite vast and trying
to improve everything would not only be a poor choice from an ROI perspective,
but would be ineffective as well. Apart from the 23 process areas that CMMi lists,
there are other areas that CMMi doesn’t touch. Refer " " for more details. There
are skills such as estimation, requirement elicitation, requirement management,
planning and tracking, risk management, test management, quality management,
team leadership, communication to name a few. Training future project managers
on all the skills relevant to project management would be as much of a syllabus
as that of a master’s degree in project management which organizations can ill
afford if all of their staff have to go through it. Therefore, choosing the right subset
of skills to train future project managers, choosing the right process areas for
rigorous implementation are key to success and this is where the business leader
has to play a key role. The business leader has to provide direction in ensuring
that the right skill sets and process areas that suit their business context are
chosen. And driving delivery excellence in such a way that improvement in
delivery is tracked all the way up to business results is also a responsibility of the
business leadership. Hence, a business leader needs some high-level knowledge
of software project management to be able to make the right choices, drive
delivery excellence and ensure that delivery excellence translates into business
benefits.
Relating delivery excellence to business results
Going into further details, the choice of process areas and skill sets has to be
based on the delivery parameters or metrics targeted. Carving out a road map for
delivery excellence has a method to it; the business head has to first choose the
delivery metrics that have maximum impact on business results in their context
and then choose the processes and skill sets that can specifically improve these
metrics. There is a wide variety of metrics available in the software industry and a
business leadership has to choose those metrics that make sense in their
business context. This is a key area where thought leadership of the business
head plays a crucial role. There are a variety of delivery parameters or metrics at
various levels of the organization and each has an impact on different business

3. parameter as illustrated in the diagram. The business leadership should have an
understanding of this relationship.
In summary, choosing the right delivery metrics to target, choosing the right set of
skills and processes to improve the targeted metrics is a responsibility of
business leadership. Even if this is done by delivery teams or a hands-on
delivery, head, it is the responsibility of business leadership to get it done.
The 3 reasons for business head to learn a bit of project management
Given the above explanation of how knowledge of software delivery is essential
to achieve business results, here are the 3 specific reasons as to why a business
head should have some hands-on knowledge of project management:
Reason 1 – To make the right strategic decisions for delivery excellence: For
software delivery excellence to yield business results, a proper road map has to
be carved out and has to be driven incessantly. A business leader with at least a
surface level of delivery excellence will be able to create the right focus (Read
" What the CMM and PMBoK don’t tell you " for more details on why smart choices
are required), ensure that delivery excellence is driven properly and track a long
chain of delivery parameters all the way up to business results.
Reason 2 – To be effective while interacting with customers: Customers, quite often
like to test the vendors during their coffee shop conversations. When they bring
up topics of software delivery in informal conversations with the business head,
the business head should not land up being embarrassed and limit himself only to
commercial details. He should be able to engage in the conversation in some
meaningful manner. Secondly, customers don’t understand delivery models and
place unreasonable demands beyond the normally unreasonable demands. For
instance, customers take refuge in agile models and use agility as an alibi to lack
of clarity in requirements. They would like to change the requirements in an
unlimited manner and yet expect the vendor to deliver all the requirements within
the fixed-price contract. The business head should be able to understand the
implications of such demands and pitch in to negotiate with the customers when
the delivery teams cannot handle the situation by themselves. This ability to deal
with customers requires the business head to possess a certain basic level of
understanding of software delivery.

4. Reason 3 – To provide motivational leadership to delivery team instead of using
authority: Whether one likes it or not, the software field is full of jargons that
creates a barrier for non-s/w person to freely interact with s/w teams in a
meaningful manner. Jargons make it difficult to get to the point and this difficulty
deters typical business heads from becoming hands-on, and freely interact with
the development team. The jargons make the business heads isolate themselves
into a closet and only use authority to get results from the development team. The
beauty about these jargons is that it takes less than 5 minutes to appreciate the
essence of each jargon and if a business head can burst all the jargons by
investing sometime, he will be able to interact freely with the development teams
in a meaningful manner and open up ways to inspire and motivate them. Hence,
the business head has to invest time to understand basics of project
management to be able to burst jargons, interact freely and provide motivational
leadership.
In summary, a business head can drastically improve software delivery and
hence the business by investing in learning basics of software project
management.
If you are a business head reading this article, what would your response be?
Else, if you have seen business heads functioning what would be your
recommendations to them? Share your insights here.