Project and Delivery Management in the context of changing software development paradigm

  (New post published on linkedin, blogger and medium blogging platform)

It has been a long since I left blogging on this space of project management. Probably managing projects and delivery kept me too busy that it became BAU (Business As Usual) for me and led more to philosophical and self-help topics in my blogging space, to bring back balance rather than about work space again. 😊 But that wasn’t the case, I was happily into reinventing myself, into doing projects and delivery management in different ways, in different context and enjoying what I have been doing. But time has definitely come (and sure so as - I am on a short break!) to write a new one and hope it leads me to writing more on this space. I will be touching upon few concepts, without expanding on the context, and hence for a casual reader it might look simplistic approach in larger organisational context, or they might overlook what I intend to convey. So having given a word of caution as to what you might expect to gain here, let me go and spill out what is in my mind.

 

The role of project management has evolved in the Information Technology (IT) industry and is probably half-way in its journey to turn a full circle. As the technology evolved rapidly from siloed to distributed development, so did the management and delivery of such projects and initiatives. Organizations and individuals who shied away from such changes and became ‘hard coded’ were the ones who struggled most and felt outdated soon. While others who clung onto the new ways, well - at first spoke differently, and then found themselves - apparently very busy and continuously adapting to newer refinements of managing things. Then it happened again. The vast majority started speaking the new language, had no choice but to mend their ways, and the marketing and sales teams found their new jargon to aid their work. I am sure most would have now guessed what this is all about – agile software development with self-organized projects/product delivery.

So, has agile software development resolved all problems that faced the earlier development models? Yes and No. Has it removed the need for dedicated project or delivery management? Yes and No. So, what works well with agile and what does not? I am not going to go into details of agile methodologies and different models here. There are enough materials out there on the web and organizations that provide training and consultation to help adopt agile practices and coach their teams. My intention is to bring again certain aspects of project / product / delivery management when projects are running on agile models for whatever reasons they chose to adopt.

Let’s look at the problems and general trends around the four agile software development values:

While there are numerous practical problems in different projects and different organization context, agile approach did provide certain retrospective ways to amend the ways of working to make them effective.  However, to help steer towards an agreed goal, there was a need for a different kind of skill set that includes facilitation skills. As agile adoption increased and evolved, so did different roles and designations associated with an IT project. While traditional project and delivery managers took on different hats while owning and delivering projects, and gained over time an ability to coordinate and facilitate delivery, their focus turned elsewhere due to the prevailing career paths for such roles. In agile, the management responsibility is split across all the agile roles, and hence whether one is scrum master, product owner or development team member or a vendor project/delivery manager playing different roles, everyone had to adapt to the ways of working and develop facilitation skills. In essence project success was proportional to team work and team success in every iteration. Let’s look at the 12 agile principles and related practices.

Any triggers that disturbed these factors may only delay the grouping of the team to deliver well within contractual obligations. As many organizations were in transitionary phase in the last decade to agile methodologies, every person playing a role in the agile development process irrespective of his /her degree of involvement faced difficult challenges to communicate the actual reality versus perceived reality. This resulted in two larger factions, those who were still on the transitionary path – across different levels in the organization versus those who made it to the new ways and were perceived religious agilist, again at different levels within the organization. But if we go back to the original ‘spirit’ of the agile manifesto, and throw away the hardened aspects, these perceptions can be refined.

So can we eradicate the role of a project / delivery manager? 😊

Not at all. There is a lot to learn and apply on holistic management concepts far from any specific methodology and avoid distributed ownership /people related risks. Many agile teams have realized this and appreciate such a role in their team. On the other side, the project/ delivery managers from non-agile experience have to learn an important aspect to adapt to the agile ways – applying their expertise to different, changing context all the time.

However, what is critical from waterfall to agile software development days, projects needed two aspects – client management and software development/delivery. And the facilitation skillset acquired by those opting the management career path in earlier days – project managers, delivery managers – are now required across the distributed self-organizing teams if they have to succeed. While most are learning the skill and adapting to the situations well – albeit with many failed projects – few things that has also worked well and has unified different aspects following agile:

• Project and technical delivery management are the same and requires similar role profiles
• Gaps perceived between product and project management have come down
• Delivery and service management are beginning to unify with agile now becoming agile devops and transitioning towards integrated development and service management tools for development and operations
• Flat organization structures with Servant leadership skills
• Managing Emotional Intelligence / Quotient / Empathy becoming a need with self-organizing teams
• Remote and hybrid working model triggering a change to the original agile manifesto of co-location with technology sprouting to support using metaverse technological advancement

And many more changes to come, as agile manifesto needs to have a retrospective on itself and adapt to the newer paradigm shift. First and foremost, it is important to acknowledge that we aren’t fully and truly agile yet in most context, as it’s a continuous improvement principle. I do think that collectively we have completed half circle, and are getting ready for the next curve in the transition towards a newer model. With changing global situation, this is going to be difficult to predict, but the core aspects of management skills are here to stay and everyone irrespective of their career orientation have to learn, unlearn and relearn to sustain the ongoing changes. Hoping to continue again on this blog more regularly as I navigate through this journey. 

P&L, Project Margin, Gross Margin

P&L, Project Margin, Gross Margin

Financial Management is a broad topic and forms the core for any business. However, I will bring some of the terms here in simplistic way for persons taking up project management role or aspiring to do so from a technical career stream. As in most of my writing in these series, my language, terminologies may be found to be more closely aligned with IT project management, more specifically from an IT Service provider delivering projects /services for its clients.

Companies do business to make profit either for the founding members or for the investors who expect good return. What does an IT project manager need to do to manage profit and margin? Does he/she have an element of control? In most cases, the finance department publishes a certain template or the same is part of an enterprise application for PMs to manage the financials of the project. Depending on the size of the organization, and the layers involved, the PMs mostly get a thin line of control to manage their profit margin at a target level, as the constraints in getting the resources (team members) and the timeline, criticality of project deliverables generally takes the margin downwards.

Given the thin line of control, it is important for PMs to understand certain basic terminologies and financial concepts behind the calculations. So, let’s get to some basic accounting terms.

Most understand profit involved in selling a product or service as the amount earned over and above the cost involved in developing and delivering the product or service.

Profit = Selling Price – Cost Price = Revenue - Cost

Profit is a number in the currency being used.

Margin is expressed in percentage of profit over sales.

Margin = [Selling Price – Cost Price] *100 / [ Selling Price]

Margin = [Revenue – Cost] * 100 / [ Revenue ]

For example, let’s assume you have 10 persons in a team working for a project, and are billable on T&M basis (Time & Material). The amount charged to client, assuming different rates for different roles charged to the client, and a period of 10 months, with 8 hours per day and an average of 20 working days in a month would be as follows.

	# Resources	Rate/hour ($ USD)	Amount for 10 months =  Rate * 8 * 20 * 10 * # Resources
Project Manager	1	$35	$56,000
Technical Lead	1	$30	$48,000
QA Lead	1	$30	$48,000
QA Engineer	2	$25	$80,000
Senior Software Engineer	4	$25	$160,000
		Total	$392,000

So, the cost projected to client is $ 392,200 and for the IT service provider, it is the projected revenue. How do we get the cost of the resources to calculate the margin? In most organizations, the cost (salary) of resources are confidential and managed by finance team through a financial system. In such organizations, the resource names and rates are fed into the system along with other project parameters. In smaller organization, the PM is aware of the salary and can compute the cost. For instance, in the above example, if we consider the following salary structure (assuming the team is offshore and are paid annually in INR), we can calculate the cost and hence the margin.

	# Resources	Standard Annual Salary (₹ INR)	Amount for 10 months = (Annual Salary / 12) * 10 / 70 (converting INR-USD)
Project Manager	1	₹ 4,000,000	$47,619
Technical Lead	1	₹ 3,000,000	$35,714
QA Lead	1	₹ 2,500,000	$29,762
QA Engineer	2	₹ 2,000,000	$23,810
Senior Software Engineer	4	₹ 2,200,000	$26,190
		Total	$163,095

The profit in the above example is $392,000 - $163,095 =  $228,905 and the project gross margin is  $228,905 / $392,000 = 58.4%

I am using basic terms and definitions of cost, revenue to help understand the difference between profit and margin. Each of these terms can further be defined as per the costing philosophies and models used in the organization and the accounting standards followed. There could be other costs in executing a project, not related to the resource’s costs, which we did not consider in the above example. 

Why do we measure margin and not profit? 

There are some good financial reasons for the same to help understand the performance of the company and for comparison with others in the same business. It is a good indicator of both the costs of operation and the selling rate and justify the margin. Increasing margin, can also indicate lower cost of operation with respect to a competitive pricing model determined by market dynamics. In my view, when the economy is in growing phase and market itself is expanding globally, with a competitive environment governed fairly for the benefits to spread across society, margins are a much better indicator of business growth. But when the economy reaches certain limit, and due to constraint imposed on the business operations either externally or internally, margins may not be an indicator of business growth, but just a financial stability indicator. Rather too much focus on margins can indicate that business might be falling apart and may follow certain predicted lifecycle model of organizations. (Refer Adizes Methodology lifecycle model). As a side note, I have my own philosophical thought on why ‘margin’ and ‘increasing margin for a given period’ have been used to further the greed of investors in a capitalistic economy. I might write about it at some other time. Overall it can be detrimental to the economy and capitalism itself. It can also indicate a transformational phase of the environment from capitalism to service mindset. I see the rising of ‘start-up’ culture, ‘servant leadership’ and other concepts proposed by management gurus in alignment with this thinking.

Getting back to our financial concepts, if we consider a single project, and the related costs and revenue, then we will get the Project Gross Margin. At an organizational or business level, the same is referred to as Organization Gross Margin (Operating Margin). There could be other costs/revenue in executing a project and running an organization. If these are taken into consideration, we can say we get the Net Margin. I am trying to take my readers slowly into the terms and concepts. (especially PMs who haven’t had much training and put on the job). Financial gurus might have other opinions, different terminologies to add to this. I would welcome such comments for me to further improve this blog in later versions.

Let us now look at what constitutes the cost component and what can be considered revenue. Costs involved in executing a project can comprise of direct costs and indirect costs. For instance, direct costs include the cost of human resources deployed, cost of any hardware or software specifically procured for the project, etc. Indirect costs include cost incurred for training of human resources, standard administration and infrastructure cost, other overheads that are shared across projects. If the project is executed as part of a specific department or unit, there could be additional costs at the unit level and hence the margin at unit level will be slightly lower than the margin at the project level. Similarly, the revenue can also have multiple components, based on the pricing model. At organization level, other overheads including management costs, marketing and sales expenses, pre-sales activity can bring in their cost components and impact the gross margin.

Hence the Profit & Loss (P&L) statement will include multiple lines that detail out the various costs and revenue and companies adhere to various accounting standard when publishing their P&L statements. The tax that organization has to pay, currency fluctuations, will also be considered to arrive at profit before and profit after tax. Another term often used, but not considered part of most accounting standards is EBITDA (pronounced ebitda) – Earnings Before Interest, Taxes, Depreciation and Amortization. Operating income or earnings before interest and taxes (EBIT) is all the income minus all operating costs, overhead, such as selling costs, administration expenses and cost of goods(or services)

EBIT = Gross Income - (Operating Expenses + Depreciation & Amortization)

For comparison among companies, the depreciation and amortization amounts are added back to give EBITDA

EBITDA = Profit + Depreciation Expense + Amortization Expense

Understanding of these terms coupled with knowledge of your organization financial model will help in arriving at different targets for margins, and strategies to be followed in achieving the same. At a project level, understanding gross margin target, project costs and revenue, and what contributes to them, are the key controlling elements will help play with the factors within a project and balance with other non-financial targets and success factors.

I have given few references, some of them that I used, and can help you take dive into  financial management further.

References:

https://www.investopedia.com/terms/g/grossmargin.asp

https://www.investopedia.com/terms/d/directcost.asp

https://www.investopedia.com/terms/o/operatingmargin.asp

https://www.investopedia.com/terms/m/margin.asp

https://www.cio.com/article/3240592/leadership-management/4-ways-to-avoid-leaks-in-project-profit-margin.html

https://www.pivotalfinancialconsulting.com/single-post/2016/10/31/Improving-CRO-Gross-Margins-with-Project-Margins

https://cleartax.in/s/accounting-standards
http://adizes.com/lifecycle/

Follow My blogs at:
Sense And Balance @ Blogspot
Medium.com
Project Management for Newbies @ Blogspot