Why you should never work for "Projects"...

If you are like me who has spent more than 1.5 decades in the IT service industry, you have uttered or heard at least ten-thousand times one specific word – PROJECT.

No matter what level you are at in this industry– a fresher or someone at the top executive level, you are either hearing or saying it 10 times in a workday at a minimum. I see you are nodding your head.

Is it time to change this buzzword, which is so much engraved in our mind and thought process?

But ‘why to change it?’ I hear you ask. Well, that is what I am going to explain in this article.

I often come across developers and even few managers working for certain “projects” who do not have end-to-end visibility. Please mind it, they are very thorough with what they are working on or any information about the current phase of the project they are in – but they surprisingly lack an understanding of the Big Picture. If you ask, “Okay, I understand you are developing so and so feature- but what is the use of it? Why does our client need it? What impact can it make to the integrating systems? Or - What if you develop it following Process B rather than A? ”.

You will be surprised to see how some of them become clueless. Again, please make no mistake- all of them are excellent team members, working/stretching tirelessly to deliver the requests and the customers too have great confidence in them.

So, is it an issue at the first place?

IMO, it may not be that of an issue if it is a small scale less than $100K small-sized project, but it will definitely be an issue for a large-scale engagement. And I tell you why if you read on further.

In this current time, where digital transformation is at its peak especially post-COVID, every organization has adopted micro-services patterns. For example, let us say there is an e-commerce retail client worth $Bn, whose entire website is broken into multiple services. There is a possibility each of such services- Search Product, adding to Cart, Purchase, Payment, Shipment, Tracking – each could entail a separate Development team where more than 100 developers are working for both front-end, backend features.

It is definitely a challenge for each team to know what the other team is working on. Every team has its own complexity, challenges to deliver their own service as they need to ensure faster go-to market.

 Large-scale Agile methodologies like SAFe® prescribe many nice approaches (Portfolio SAFe®) as how to sync-up with all such Agile release trains or teams.

But in reality – even after several rounds of PI Planning and scrum meetings you may not be really safe :).

The reason is -mostly Developers focus on the “Projects” or the Agile POD/team they are assigned to – and their focus becomes narrower with each passing day. The more granular your work becomes – you are stuck with your Sprint goal, backlog refinement, delivery , POC , code commitment and challenges in each phase of delivery- the more short sighted you become. The same thing applies to the Project Managers as well. They also start huddling with planned vs. actual – ranging from Story point overflowing to next sprint, technical and process debts keep piling up , many internal and external process of reviews/audits/status reports starts hammering their way to their TO DO list- everybody either forgets what they set to achieve or what client really wanted out of your “Project.”

To put things into perspective- let us assume there is an API team (let’s call them Purchase API team) that is working on confirmation of purchase with inventory (usually another API team) and there is another UI team that shows the available product. This UI team typically works with another middleware team, which invokes the request to our Purchase API Team.

You can very well land in a situation where the developers working with the Purchase API simply says – I don’t know how Inventory team shows the product and UI team says they have absolutely no clue how the purchase is really happening at the backend. Do you think they should know that?

Do you think it is an issue at all?

Well – to me it is a big issue, which can put the client in jeopardy. The products can be shown not only if it is available in Inventory but also the right request parameters purchase API team is sending and vice versa. I know there will be a Swagger contract they shall be following etc. etc. but what about the implications? The business logic behind the fields all the teams are exchanging?

The API team only sends response to a call that is made to them. If they do not know what the response means to the calling parties- things could very well go south for the product owner.  

I have observed that if you lose your sight of the Big picture, don’t keep a check of what downstream and upstream systems your so called “Project” is interacting with- how we are so sure the story we are marking as DONE in JIRA® or VersionOne®- is not giving birth to another defect story in some other teams’ Agile board?

I have faced such escalation, challenges and when I sat down to do a causal analysis- I saw that everyone did their job perfectly and delivered what they were supposed to flawlessly.  Still the project failed to deliver the desired outcome because everyone was so focused in completing their own tasks- they forgot what impact it was causing to the some other team.

Now, so far I only talked about the problem. Is there any solution to this? Is there any method to this madness? I have tried something and I feel this could solve the issue eventually.

There are already many proven methods and most of them either are already in place at client end or Service organization end. Therefore, I am not going to introduce a new process. Rather I would recommend a shift in the thought process.

Please consider teaching the team- starting from developers to managers, they are working on a PRODUCT, always. A product serves a complete solution to customer. It is thus a necessity for anyone working for that Product to know the critical success factors. A Product is only successful when you know what it offers to its consumers, what affects the health of the product and what intensifies benefits of the product.

Once you start treating your “Project” as a “Product” – our clients can expect we will be interested to know all the downstream and upstream systems that interact or influence the Product.

Moreover, with the Startup boom – I felt IT service employees somehow felt left out.

Somehow, I have sensed suddenly it is not cool enough to be part of Service Companies. Without demeaning anyone – every type of organization has its own merit and demerits. It is very hard to say which one is better without really seeing both sides. At the same time, the learning can be equally rewarding for both types of organizations.

Millennials especially may be intrigued if you can influence this Culture within your team or organization. IT employees belonging to Application/System/Infrastructure services industry –constitutes nearly 60% of the total workforce as per study so we as leaders really need to work hard to unlock their potential.

People management is a tough job and most of it is an art than science. Most of the times we can unleash our enormous potential by simply changing our mindset than any formal process or methodology.

A word of inspiration can go a long way than some documented process, in my experience.

Let us go back to the example of our Purchase API team that is only immersed on their daily tasks, story completion and sprint demos while their managers are busy with burn down charts, spill over stories and next sprint planning/grooming.

Do you think if you can percolate the thought that they are not merely working for an “API project” that the client has assigned them, BUT they are working for a Product, which offers a complete 360-degree service for their customer, it will make a difference? A Purchase API PRODUCT they are developing is integral for the Client’s e-commerce business. Do you think they will be interested to know what the ecosystem of the Product is that they are delivering? Also if they miss the POV, what impact it can bring to their client?

Well, I tried and it worked for me. I agree though it is not an overnight magic but a steady process. 

Think of it for a moment.

It can infuse fresh energy and pride in the team. Leaders play an important part here.

They need to constantly remind the team of the ownership/ responsibility they are carrying for their client. They also need to do their part, which is- lead the way.

So, train managers first so that they are convinced and then influence the entire team. The combined synergy can bring tremendous result for the Client and the team.

The Product team that cares about its consumers, is self-reliant, takes pride in what it does, is always curious to know the touchpoints and the impacts the product makes to those touchpoints, is bound to create an impact. There shall be no looking back from that point onwards.

So Repeat after me....We are not working for "Projects" but a "Product".

What do you think? Do you think it is worth a try?

You may leave a comment....

#Leadership #Product #RepeatAfterMe #Digitalera #Management #Agile #SAFe

#DeliveryExcellence