Showing posts with label IT projects. Show all posts
Showing posts with label IT projects. Show all posts

Thursday, 10 July 2025

Thoughts on Project Management

Today, during a session on understanding a project, I shared this format which the class loved. 

To understand all the dimensions of a project, just go over the 7 vibhaktis of Sanskrit 

Karta ne - कर्ता  ने - Who is doing this project? 

Karm Ko - कर्म को - Exactly WHAT do we want done? 

Karn se - करण से/के द्वारा - What are the tools/tech platforms that we will use to deliver this project? 

Sampradan ke liye - संप्रदान के लिए  - For whom is the project being done? (End users and key stakeholders) 

Apadaan se prithak - अपादान से पृथक -   Who are the people/entities who will lose some ground/role after this project goes live? Who will be alienated? 

Sambandh Ka, Ke, Ki - संबंध का, के, की - All related entities that share an interface/data exchange with the project. 

Adhikaran Mein/par - अधिकरण में/पर - What all will this project encompass? What business processes does it own? 


We created a 360-degree view of the project using this thought process and it was a huge success, allowing us to identify our stakeholders and our scope in a fun way. 

Friday, 29 October 2021

How to Manage Client Scope Creep

This post is the result of a good conversation with Abhishek at a recent event. 

He asked how we managed to ensure that there was no scope creep. My projects have usually been on track and within budget, and as Abhishek mentioned, client scope creep is one of the major reasons why large IT projects go out of budget or schedule. 


So, if you are a budding project manager responsible for client management, here is the secret to building great client solution and even better client relationships. 

Most client scope creep comes from 2 areas: 

A. Complex Workflows, where more approval levels are added. 

B. Reports 

The first thing you have to remember when dealing with client scope creep is that they are not trying to trouble you. Their intention is not the squeeze the juice out of you. Their intention is to do the best that they can for their company at the least possible price. 

Surprise! That is your intention too! 

Most vendor PMs do not understand this intention and objective synergy. But when you do, you realise that you and the client PM are on the same side, trying to do the same thing. 

The only thing is, we are using two different approaches to do it. 

So, Step One:


Establish Commonality of Purpose 

Sit down with your client and establish commonality of purpose. Both of you are working towards the same thing: 

A. Create the best possible solution

B. In the least possible time 

C. At the least possible cost

Once it has been stated, it appears intuitive. Yet, until we say it out and put it on the table, it is not so apparent to the other party. In fact, if you wait at the water cooler long enough, you will definitely hear the Project Managers from both sides cribbing. The Client PM usually says one or more of the following: 

  • The vendor does not want to do any work or wants to do shoddy work and get away with it. 
  • They are not doing enough KT 
  • Even for small change they give such a huge estimate, and change request for everything! 
  • They just don't understand our business and requirements. I don't know how to explain. 

The Vendor PM will usually say one or more of the following: 

  • The Client is really miserly. 
  • They always underestimate the time it will take to do something. 
  • They are paying us for a cow and want us to make an elephant. 
  • They don't understand how the system works. 
  • They have such weird requirements! Who works like this? 
So, the step of establishing commonality of purpose is the most important one. It establishes trust and ensures that you row on the same direction, not in opposite directions. 

Once commonality of purpose is established, the next thing is to understand where scope creep is coming from. 

Step Two: 
Diagnose and Guide 

Most scope creep comes from the two areas I have mentioned above. You do your own diagnosis on your projects and understand WHERE the scope creep is coming. And then ask yourself WHY. 

What problem is the client trying to solve by doing this extra work? 

Let's get straight to taming the beast. 

Step Three 
Managing Scope Creep and Making Great Friends 

Here is the most important tip anyone will ever share with you on managing scope creep. It is so important that I am going to write it in caps. 

START WITH YES. 

Whenever the client asks you whether something can be done, NEVER start the conversation with No. if you know that it can be done, start with, "Yes". If you are not sure, start with "We will try to find a way to do this." 

Managing Workflow Complications



Most clients who try to add additional approval and exception workflows are basically trying to tame one beast - Compliance. 
That is the core objective. 

Start the conversation by saying - My work ends with doing the coding. Your work starts after that and goes on forever. So, my work is the shorter one. Let's talk about how this will work after go live in your business. Let's discuss a few scenarios and understand how much additional work it will add for your users, and what you are doing about it now. 

After that, listen. Let them explain all their use cases and exceptions. Understand their compliance needs thoroughly and most importantly, understand how users manage exceptions now. A system that can be excepted by the user in an emergency will eventually be excepted as a matter of course. The user's onboarding learning curve is slow, but their bypassing learning curve for any system is amazingly steep. So, if you make it necessary for users to bypass the system for one thing, they will be bypassing it for most things sooner than you realise. 

After the client has finished putting their requirements on the table, don your product specialist hat (or get your product specialists on board) and design a solution that meets their needs without being overly complicated. I can assure you that most workflows can be simplified. 

Pro Tip: For each workflow step, ask your client: 
  • How will this step increase the transaction load of the user? 
Let's understand this with a real life example: 

Let's say that the client wants all travel to go to the department head. The questions we ask then are: 
A. How many travel requests will the DH have to approve in a day? Week? Month? How much time will it take them to approve each (assume reading time). If we go with 5 a week and 5 minutes per TR, that's 25 minutes of extra work per week. For an already stretched executive. 

Next, ask them how they plan to manage situations that are definitely going to arise - the executive on leave, too busy, traveling himself, etc. 
Usually, in such cases, a thing called Delegation of Authority is used. 

Let the client think about that. And then help them understand how to balance compliance with minimum transaction load on the users. 

  • What value is this step adding to your process? 
The most frequent response to this is "It gives us better control" or "Compliance." 

Do not resist. After the client says this, sit back in silence and let them think. 

If they do not appear to be making headway, ask gently, "Are you creating a better process, or are you helping someone do CYA? Think about that. If the system can be hacked, it will neither lead to better compliance nor control. Every new control element you put in there is also a hacking opportunity. Think about the real business value of every step. And its real objective." 

Always be mindful of the client's imperatives. 99% of the times, clients see the difference between business value and CYA. But some cultures are necessarily CYA cultures. In those cultures, you can only help the client by perpetuating the CYA culture. Do that. 

And most importantly, NEVER disrespect the client - neither in public with your team, nor in private in your head. A Lot of delivery managers and PMs get together to laugh at clients in private. The client does not know tech as well as you do, and you don't know business as well as they do. Further, respect cannot be faked. Come from a place of real understanding, and you will create synergy. Come from a place of negotiation, and you will create a tug of war. I am still in touch with client PMs who worked with me 15 years ago, and more. 


Managing Reports 

Report requirements are the biggest headache for most PMs. The client wants to extract every element of data being put (or not put) into the system in about 15 reports on average (that's a joke, not a statistic). 

So, how does one tame the report monster? 

There are, once again, 2 simple questions that one asks the client. 

Since I have dealt with dashboard design and report management in another post, will just quickly state the 2 questions here: 

A. Who will enter this data? 

Request the client to go through their entire data flow process (you can use a proprietary methodology I have listed elsewhere on this blog - the Data River Diagram) and have them understand how the data will flow into the system in the first place. 
Is there enough reliability of that data for us to use it in reporting? 

B. What decision will it aid / How will you use it? 

Every pixel on an executive dashboard is important. Every second of executive time is important. If a data element is making it to reporting, it must help the user do one of the following: 
A. Monitor and control 
B. Diagnose and Correct 
C. Predict and Decide 

If the report is not fulfilling one of these 3 objectives, it should not be there. 

Your clients will truly appreciate your trying to create reports and dashboards that are relevant for the long term. 
In fact, invest some time in creating a report library that you know helps other organisations create effective dashboard and reporting interfaces, then proactively share it with clients. Will significantly shorten the cycle time and will also help the client see value in your work. 

So, are there any best practices that have helped you deliver better business value to your clients? Do share! 

Friday, 10 September 2021

Why we chose Judgify.me as our Contest Management Platform

We wanted to do a start-up contest for students. That meant that we needed a contest management software. 

The first step was to search for a WP plugin that offered an end to end contest management. We did find a few but they needed integrations, or were missing some key functionality. 

Next, we evaluated YouNoodle. 

Younoodle was already the platform being used by another startup contest where I was on the jury. The UX was so bad that we put it in the negative list almost immediately. 

After this, we came to the final step - yes, SaaS: An external platform that offers end to end contest management functionality. 

Our key asks were: 

A. Good UX, because this was for young students. We didn't want a data heavy, clunky UX. 

B. Flexibility. 

C. Ease of use 

D. Privacy 

E. Functionality - Assignment of Judges, Judges should be able to view and score online. 

F. Admin should be able to assign judges, see when they have scored, who needs nudging, and download scores, etc. 

G. User experience should be intuitive and easy. 

In the end, it was between 2 platforms : 

A. Dare2Compete 

B. Judgify 

Dare2Compete is a full fledged, feature-rich platform that caters to end to end contest management. The other thing that worked in favour of dare2compete was that it takes 3% processing fee for fees collected and also gives us access to its own native set of users. All events are manually checked by a review team before being approved, so that quality of contests available is also quite good. 

Judgify.me, on the other hand, appears to be a more recent platform. 

Eventually, we chose Judgify.me over Dare2compete. For those of you looking for a SaaS platform for contest management, this experience might be useful. 

  • Friendly URL
Our URL was simply judgify.me/empower. This is easy to remember. It was customisable. A friendly url makes a world of difference to user experience for participants. 

  • The creation process
The contest creation process at Dare2compete is very thorough. It is also long and does not allow us to save as draft. One event creation takes 30 minutes. It took 3 efforts to create a single event. 
  • The event review process 
This, I thought, was a plus with Dare2compete.com. It builds the credibility of the platform. The review takes under 24 hours, and ensures that the quality of contests (and by extension, the quality of participants) we get is likely to be good. Judgify.me had no review process. Since we did not depend on the audience at judify.me, it did not impact our experience of the platform in any way. If we had wanted to borrow audience, we might have given Dare2compete more weightage. We did list the event there though, and got 6 registrations, none of which paid the registration fee. So the audience premium did not really translate for us. 

  • The UX - Contest Participant 
Clearly, this was the clincher. The UX of Judgify.me for a contest participant is very easy, intuitive, and flexible. It allows the user to: 
   A. Partially enter their data. 
   B. Save entry as draft. 
   C. Make changes after submission. 
 
We found that the screen flow was very intuitive, did not involve a lot of learning for the user, and was neither clunky nor field heavy. There weren't so many fields that a person gets intimidated, nor so few that we can't get the information we need. 

  • The UX - Jury 
When I tested the Jury interface, it was so perfect! When we register on Dare2Compete, we find that the jury member gets an email saying "password reset required." The jury member would and should not click on such an email. One does not password reset on a platform where they have never registered. We asked support if we could change the content of the email OR suppress it entirely. They said that both are not possible. That was a deal-breaker. That was not the experience that we wanted our jury members to have. In this day of security consciousness, password reset is absolutely the most unacceptable subject line to have. 

  • Admin UX 
The Admin UX is adequate in both. There is some learning curve and some manual work that needs to be done. In Judgify.me, some jury members did not receive the emails and asked us to change the email id. So, I had to create them as a new entry. But overall, the Admin UX is fairly intuitive and we found it to be better than in Dare2Compete. 

  • Support Responsiveness 
Another super important area for any event organiser. On this front, Judgify.me wins hands down. 
Disclaimer: In spite of being an Agile PM for over a decade, i am never in a hurry. When we raise a support ticket, we always have at least a 10 hour window for its solution. So, if responsiveness means 5 minutes or less, or if you are the kind of organiser for whom everything is L1, this rating may not be useful. 
Dare2Compete was only available on email, with an average response time of 24 hours. Further, there was no continuity in the messages. 
Judgify.me had a much shorter response time. But what was better was that even though it was only emails, one knew that one was talking to a real person (Joseph, in my case) and there was continuity. 
Expect an average response time of 2-5 hours. 

So, that is the story of how we chose our contest management platform. 







Tuesday, 5 January 2021

How to stop your KMS from being your MIS

This was a very interesting discussion. An organisation had just set up their KMS and were wondering about information structure. 

The project manager asked a very intelligent question - How do I ensure that my KMS does not become a document repository, and remains a knowledge warehouse? 

Here is, in brief, the answer: 

What goes into a KMS? 

To understand what goes into a KMS, we have to understand what a KMS is. The best way to understand what a KMS is, is to know what a KMS is NOT. KMS is not: 

MIS 

It is not meant to give you timely information on your operations and help you monitor business as usual. 

DMS

It is not a Document Management System. It is not where you dump all your reports, proposals, policy documents, etc. 

DSS

It is not a Decision Support System. All information in the KMS repository is, by and large, time agnostic. Like the Vedas and Amar Chitra Katha, the wisdom in it is for a long time, of course, updated with the times. But not time sensitive. That is the crucial aspect. 

A Knowledge Management System is just that - a system to manage the knowledge in the organisation. 

So, to be counted as knowledge, an artifact / document must be: 
A. Time agnostic
B. Be applicable in a wide variety of domains. If it is specific to that one project, that one report, and that one employee, its not KMS worthy. 
C. Be clear about the knowledge it imparts. 
D. Ideally, help a person connect the dots and lead to some business value.
E. Must not include any confidential information / company identifiable information.  

Some examples of good KMS usage 


Katy is looking for ways to quickly do effort estimate on her bids. Obviously, the information is incomplete, and she has to do her best. She finds out, over a period of time, that if she has some key data elements, she is able to give a bid that is very close to the actual costing + margin of the organisation. 
So, she prepares a questionnaire that has all these data elements. 

Now, whenever the bid team receives a RFP (request for proposal) , it sends this questionnaire as its standard list to the client. The bid team then has the info it needs to create a clear bid in a short amount of time. 


******************* 

Raghu, the Finance head, is sick of asking departmental heads for TCO (Total Cost of Ownership) before approving their capital procurements against Budget Line Items. 

Exasperated, he creates a TCO Calculation template that he just uploaded into the KMS. Now, before sending the proposal, everyone looks at the TCO calculation template. This has also helped other department heads identify the hidden costs in their procurements, which were earlier blind spots. 

************* 

How to ensure the success of your KMS

  1.  Keep a tight gate on what gets in. 
  2. Incentivise reuse of artifacts as much as possible. 
  3. Monitor usage at all times. Even plants atrophy without fresh air and anything left untouched starts to decay. KMS is not a dead system. It is a living, breathing system that supplies vital nutrients to your organisation. 
  4. Guard against plagiarism. It is unfortunate, but not rare, for employees to copy stellar documents written by someone else and submit them as their own KMS submissions. 
  5. Incentivise participation. If people are hesitant to create documents, give them sample documents and offer surprise prizes for lucky submissions. Hold a contest once a month every 6 months - for both submitting and using artifacts. The contest for using artifacts will also give you the case studies that you need to create emails about KMS use. 

How long does it take? 

6 months. This number is usually independent of the organisation size. It will take people about 6 months of consistent, persistent reminders to make a habit of using KMS as a regular part of their work. Plan your Change Management for 6 months, and keep plenty of budget. 

And Finally: 

What makes a good Knowledge Management System 





How to Design a Dashboard for yourself

 Many years ago, I wrote this post to explain durable dashboard design. 

A durable dashboard is not a dashboard that is used by the client for a long time. All dashboards, once developed, are used by client organisations for a long time. 

But they are not used by the people making the decisions. Their Decision Support System inputs start flowing in, as they always have, from outside the system. 

That post tries to address the issue of creating dashboards that remain relevant for the user for a long time. 

This post is for managers trying to create a dashboard for their own use. Obviously, its technology agnostic. You know what tools you use and how you can make it better. The post will only help you ask the right questions and find a way to design something that works for you. 

How to create a dashboard for your personal use 



Step 1: What do I want to know, and why? 

This may sound like a no brainer, but you'll be surprised to know few people actually start with this question. What do you want to know? 

Let's say that you are a talent acquisition professional. There is a mountain of metrics that you need to be tracking. Which ones need to be on your dashboard? The  higher up you go, the more aligned this will be with the organisational metrics. 

Make a list, then discard 

If this is the first time you are doing this exercise for yourself, it makes great sense to create a larger list, then eliminate entries until you arrive at a manageable number. 

Why do you need to know this on a daily basis? 

Let's be clear - there are reports, and there are dashboards. Dashboards are what many of us wake up to. Reports are what we see once a week, month, or quarter. If this isn't something that you need to see on a daily basis and track, then it should not be on your dashboard. 

If you do see something every day, ask yourself WHY you see it. Which decision making does it support? What does it help you control or monitor? Sometimes, we track some metrics just because we like them. It is time to be ruthless with self. 

Once you have a list of the numbers you need on your dashboard (and not before that), please move to the next step. 

Step 2: How do I want to see them? 

This is as important as Step 1. Do not underestimate the importance of visualisation. And, there are few best practices. Understand how YOU want to see these numbers. Today, the tech investment needed to see even some of the better visualisations is not too high. But its important that you should be able to interpret the numbers at a glance using the visualisation. 

Common Mistakes to avoid 

  • A 'cool' visualisation: Heat Maps, Dials, are all great. But does your brain absorb them instinctively? Do they tell you all you need to know?  Does traffic light always meet your needs?
 
  • An incomplete picture: When we travel from numbers to visuals, the first planned casualty is the detail. So, when you choose a visual, please ask yourself it it tells you all you need to know, and only that which you need to know. Do be ruthless on both fronts. 

  • Heavy to load: A slow loading dashboard starts off being cute, moves to being mildly irritating, and ends up being abandoned property. Choose visualisations that are quick and efficient. 

Step 3: In what order do I want to see them? 

This is the last step, and as important as the first two. 

Sit back and imagine your dashboard. Wireframe it - using a tool of your choice (mine is pen and paper) and imagine yourself using it. Since you are the only consumer of this, there is no one to impress. Only you. Which report goes where on the screen WILL impact whether you see it at all, and how well you process the information. 

Once you do all these 3, congratulations, you are all set to develop the personal dashboard. Today, there are multiple DIY dashboarding solutions available, the simplest being MS Excel, which exists on most laptops. 

When is it time to redesign the dashboard? 

When any of the following happens: 
  • Role Change 

  • Change in organisational priorities

  • When a project /program / department you are tracking moves from scaleup/development to stability or vice versa 

Important end note

Even if you have designed this dashboard, do give yourself time to 'break in' and start being productive with the dashboard. A week or two is par for the course. See how you use it, what elements work best for you, whether you want redesign or restructuring. 

Once we start using dashboards for every day working, data based decision making comes naturally. So does the ability to ask the right data questions when faced with a decision. 

Tuesday, 22 September 2020

The Data Journey Diagram/Data River Diagram

Today, I am going to talk about a tool that I have just created. The tool is here for discussion, but NOT for re-use or re-distribution. Please use your conscience and do not re-use this tool without my permission, (which can be had for the asking).

The tool is called the Data Journey Diagram.

What

Graphical illustration to help users understand the usage of data generated by them, and to help BI designers see the most expected fallacies in their data.

For

Primarily, the tool is for the end users who generate data and the Analytics consultants who design the analytics solution for an organisation. The other stakeholders are the IT department, legal, security and line businesses.

How

The tool is very simple. We put the end users, the MIS team, and the data analytics team in one room.

Then we create a meandering river shape on the board. The Analytics Consultant puts a simple report at the end of the line. Then, he puts in all the data elements that go into making that report.

Slowly, each stakeholder who owns each data point, writes down where each data element comes from – all the processing points, and all the hands that the data element passes through. The river is used as a rough measure of time flow.

For each data element that comes from a different source, at the point of convergence, we draw a separate line to indicate a contributing tributary. Then the journey carries on backwards until we have a river system in place – indicating all the places where the data comes from, how it all comes together et al.

 

Ground Rules

At each stage, ONLY the stakeholder who owns the data at that point, will be allowed to create a “milestone rock” and name it. No one else.

 

Limitations

This tool does NOT:

A. Indicate dependencies.

B. Indicate And/or relationships

C. Indicate mathematical or logical operations. We know that 2 data elements come together, but we do not know if they use averages or totals.

 

What is achieved

At the end of this exercise, end users are able to appreciate, in very simple terms, how their data errors impact decision making at the CEO level.

The Analysts are able to see sources of the data being used in the high end analytics reports, and can talk to the stakeholders right there to find out if there are any anticipated data errors – time lag, fallacy, human error etc. These are VERY important inputs for the analytics design team, because GIGO is as true today as it was when computers were invented. 

So, what are your thoughts?