Bharat Jodo Yatra

For the last couple of months, a substantial amount of my time is spent on following up Bharat Jodo Yatra and listening to the speeches of congress leaders and social activists. Somehow, I find the video streaming oddly satisfying to watch, and just seeing Rahul Gandhi, walking on the road, and meeting with people in a jovial, and attentive manner conveys hope to many of us who understood the nefarious design of Godi media and troll armies. The yatra would certainly go a long way in history as a last-ditch effort by congress leadership to revive their organizational structure and dispel the confusion and myth about leadership personalities. Would it convert in a vote bank is a million-dollar question? Irrespective of the Yatra's impact on Congress's fortune, such a yatra was needed to counter Godi media designs.

But, given the kind of reforms that India needs, the bigger question is what kind of political setup Indians must elect? Looking at Rahul Gandhi's unconditional love and socialistic approach, it is difficult to imagine that he would be taking a hard decision on issues of urban reforms, religion, or the environment. However, even BJP has failed to resolve these issues. Whether it is widening of roads in urban areas, or the removal of unauthorized structures the technology enabled smart cities, the Modi government has not shown the resolve. Even from the policy perspective, the decision to implement women reservation or phasing out of SC/ST reservation or other tough decisions like judicial reforms, and electoral reforms could not see the light of the day. 

Hence, India needs another yatra that could help in building consensus around larger developmental issues. Let us see which political party would show that resolve to undertake this yatra.

Ten reasons why the team projects fail?

1. When people in the team stop taking ownership of ideas, events, and sub-projects

2. When members of the team are confused about their roles

3. When there is a lack of transparency among the team members

4. When members develop insecurity and a culture of backbiting in the team

5. When the team is trying to solve multiple problems in a diffused manner

6. When the tools and mechanisms of exercising authority and establishing accountability are missing among team members

7. When the organization is top heavy

8. When the team members do not take pride in the work they do

9. When the leadership is not able to appreciate the complexities of the task

10. Lastly, when the processes are given too much attention or they are ignored

Interestingly, most of these things are commonly observed in e-governance projects. Consequently, most e-governance projects fail in the implementation or operation phase.

Substantiating this further,

1. When the decision-makers stop attending regular team meetings, consider the project doomed.

2. When the leadership gives inconsistent direction to the subordinate members.

3. When the members of the team do not know about each other work

4. When members discuss people more than ideas and events and there is in-group outgroup culture developed in the team

5. When the requirements are received in an ad-hoc manner and consistency in the end objective is missing

6. When the standard tools for work reporting, task allocation, and monitoring are not in place

7. When more team members do not know excel and ppt than the team members who know it

8. When members ridicule the project on which they are working

9. When leadership trivializes the task of subordinates and the implementation team

10. When the documentation, bureaucratic approvals, and reporting act as an overhead to the strategy of  trial and error, and fail fast strategy 

Series Project Management: RFP documents

This blog series is dedicated to project management of e-Governance projects. The e-Governance projects are peculiar due to the involvement of the government as a client. Here project management is a three-front exercise involving IT application management and bureaucracy management of both the client as well as vendor. This setup is different from the normal client-vendor model that is marked by ownership and professionalism. In this series, I would summarise my observations and suggestions for the effective management of such projects. the In this blog post, I will share my insights on RFP documents.

RFP documents: RFP is one of the most important documents of any project in the government.  It focuses on capturing bigger functional objectives. However, many times, it misses out on small aspects that could impact the quality of the delivery.  Some of the suggestions for the RFP document are the following:

• The document should detail simple definitions like what is system or who is the user in order to avoid any misunderstanding.
• The document should be treated as a legal document and any full stop or punctuation mark should be evaluated from the perspective of requirements and delivery. In the event of a dispute, all arguments boil down to the RFP and associated MOU document.
• The document should list the necessary tools and technology stack that should be deployed for proper monitoring and execution of the project. For IT projects, the use of standard project management tools, APM, Bug tracking, code repository, single sign-on, and communication tool should be put in place.
• The document should cover how finance is going to be linked with operations and delivery of the project. 
• The document should define the service level agreements (SLA) on which the project should be evaluated. One view is that such SLAs should be part of SRS and FRS documents however, it is advisable that RFPs mention some open-ended clauses related to SLAs that can be referred to in the event of a misunderstanding between the vendor and the client.
• RFP document should clearly state the ownership of the code, resources, and level of transparency in the execution process by clearly listing out the authority and mandate of the department.
• The document should give equal importance to post-completion operational phase clauses. 
• Least of all, the RFP document should cover learnings from past projects.

In the next post, I would summarise all the major steps and documents involved from ideation to delivery of the e-Governance project.

.