When on the CLOUD, Mind the Gap(s)

The CLOUD is here; it is here to stay, say and sway. Think about any business and chances are they are on the cloud already. Right from the simple web mail, to the moderately sophisticated Video collaboration tools, the Lync, sharepoint and other communicators, to the most complex CRM, ERP Dashboards, every tool that we use is on the cloud today- unknowingly, we are on the cloud more than we know.

With all its benefits of speed, flexibility, cost and variety, the cloud suffers from some drawbacks at the implementation level.

1) Contracts and administration: I believe there is still a lot of weakness in Businesses' understanding of cloud contracts. Applications that are outsourced to the cloud come with thick contracts, which are very technical and not too easy for businesses to understand immediately. For instance, how is the payment really scheduled? What is in-scope? The grayest of all areas lies around maintenance and changes. It becomes difficult to understand what truely constitutes a change request and what is indeed part of the support package. Is it surprising therefore that most businesses tend to never use all that they buy? The packaging, in my opinion, makes it difficult for businesses to buy exactly what they need- they land up buying a lot more and then never use everything they buy in a cloud contract.

2) Time to implement: Cloud applications dont simply "WALK INTO" a company. Its not as if a business decides to implement a CRM application, and it magically becomes available tomorrow. Cloud applications have to be IMPLEMENTED like any other. They have to follow the usual project delivery process that any business usually follows. This is mostly done by way of the usual application projects and typically takes months to implement. By any standard, any simplistic application will take 4 to 5 months at the very least, before the end user actually starts using it. This greatly diminishes the advantage that cloud applications bring- customized, off the shelf and READY TO USE. I like to use the phrase "This clouds the cloud"

3) Implementation issues:  A common practice in many organisations in project delivery is to test the application from the point of view of security-the web applications testing as we commonly know it. This is where technical teams typically BREAK the application from various points- SQL Injection, un-necessry DB privileges, unsecured transmission of data, SSL implementations etc. While such testing is common place for in-house applications, it is not easy to test cloud based applications for such gaps. Cloud vendors sometimes have a problem with letting a technical team BREAK their application, for this may compromise the data of other customers, cause issues etc. A way around this is to have the cloud vendor provide a certificate from a 3rd party that his application is secure and follows the usual web application standards and guidelines. But this can be costly and the cost immediately gets transferred over to the client. One way or the other, cloud applications suffer from issues at the implementation level which mar their proposition of being cost-effective.

4) Support Model: Cloud and 3rd party applications are fundamentally changing the way support departments, or operations department are serving their end users. The concept of the HELPDESK is shifting fundamentally. Earlier, and for the longest time, every time an end user would face an issue, he would simply pick up the phone and call up the help desk. Or, he would log a ticket in his remedy system. But with the advent of cloud, support has moved to the 3rd party- indeed, this is one of the biggest value propositions of the cloud- to transfer support and ownership issues to a 3rd party so the business can focus on its core areas.
But this has its own complications. Because the application will be supported (read HANDS ON issue resolution), help desk and operation teams will not get totally familiar with the hands on issues of the applications-they aren't even expected to. In such a situation , whom does the end user call? If he calls the help-desk, are they expected to turn him away under the pretext that this is a cloud project and that he must call the vendor? If so, and if the user is indeed supposed to call the vendor support directly, this adds a change in the usual ways of working of the end users. This is something businesses don't like to see happen. This also involves training the end users to use the new ticketing system, and introducing the risk of having multiple such ticketing systems, one for each cloud application or vendor.
On the other hand, if the user still is expected to continue to call the help desk, then the help desk must be trained to route this issue to the vendor. This means linking the 2 ticketing systems together so that the vendor recieves the ticket without the end user experiencing a change in his experience. One way or the other, this involves BRINGING THE VENDOR into the business organisation- either by way of remote access ,or onsite support or something else. Either way, this adds cost and complexities, most of which must be borne by the business.

In my opinion, the last 2 issues- implementation related and the support model- will continue to cause disclaimers in cloud implementations. The entire cloud model must move to the next level of maturity to seamlessly integrate cloud applications with the usual ways of working within businesses. 

Its a RISK to ignore the RAID log

The RAID Log means so many things to so many Project Managers. Some (including me for a long time) look at it as a mere Risk Register to record those one-off risks in the project- delays in milestones, approvals not coming in time, a failed UAT, a defect somewhere etc.

Some (including me now) use the RAID log as a very important tool that AIDS the PM. The 4 components of the RAID log are crucial components of the Project Mgmt tool set at the disposal of a project Manager. Here is why I love the RAID Log so much:

1) RISKS: The conventional way of logging risks is to identify them in the execution stage, and that's not right. The process of collection and identification of Risks begins on the first day. For instance, every project deals with and processes data of varying complexity levels. This means identifying recommendations such as data encryption, security tests and DB encryption etc at the beginning of the project. These recommendations get implemented in the solution. This is the best way to use the Risk Register of the RAID. Log a RISK for this level of data complexity, identify these recommendations in the mitigation, and put them in the project plan or in the design document. Remember, the RISK log itself just acts as a placeholder for things that can go awry. It is how and when the mitigation is implemented that is more important. This is a great example of how the RAID log can help in designing, planning and tracking, not just in identification of a RISK.
A good way to make sure all risk are being covered is to conduct a risk identification session once every week or two with the main stakeholders.

2) Assumptions: Log every assumption there is to assume! and act on it, confirm it or reject it! Far too many problems in the project happen later because things were ASSUMED, but not recorded. The simplest example is to assume the business will drive the UAT. Much as the project manager holds this as universally understood, it is not always evident to the business that they are the ones who will drive the UAT. Most businesses may have a generic impression that they will get a chance to REVIEW the product before implementation, but thats about it. It is best to record this in the assumption log and align with the business. Keep revisiting assumptions every now and then, and make sure everyone knows what is being assumed. False and unidentified assumptions can cost the project dearly.

3) Issues: This is the trickiest area- things that HAVE GONE WRONG. These items find their ways into the escalation sections of the status reports on most occasions. Most importantly, correctly logging an issue and its mitigation plan demonstrates to the sponsors that the PM is still in control of the project. It also highlights to everyone involved that we have a problem, and we must all work together to resolve it soon, before it impacts other things.

4) Dependencies: This is the subtlest of all the components, yet so important when used effectively. There is a reason why the MS Project is a very popular PM tool today, and that's because it respects dependencies like none other. I once worked on a project wherein, a particular person sitting in the USA would activate a site, only after which it would be made available to users the next day in my country. The problem here is obvious- the time difference between India and USA meant he would do this when i would be fast asleep in the night. What if he failed, for any reason? How would he contact me to inform me in the middle of the night? Importantly, how would I tell my users, before 8 am that the site cant be used? This is a classic case of how useful dependencies can become. I logged a dependency, aligned this with his team, and ensured there was enough backup and communication between the 2 teams, to wade off any last minute hiccup. Dependencies are usually followed by clear and crisp regular communication, with a call-to-action at a particular date. When dealing with multiple teams each with a contribution to the project, not using the Dependency log is invitation to disaster. Planned leaves, back up plans, are other classic examples of dependencies.

In conclusion, the RAID log acts as a written contract between all concerned parties in the project, and gets everyone on board to act when required. The RAID log is not just a save-my-skin tool for the PM, it is so much more. When used correctly and effectively, it can act as a tool that can help the PM plan, design, execute, monitor and close the project well.

What's not to love about it then? 

Have you transitioned that project yet?

Transitioning a project to the support team post implementation can sometimes be a project in itself! Lack of clarity around the roles and responsibilities, lack of accountability, some kind of skepticism in the mind of everyone to take up something "new" are the primary reasons why projects take as much time to transition over (sometimes more) as they took to get implemented.

In my opinion, Project Transition becomes difficult, primarily due to the following:

1) Lack of clarity around roles and responsibilities: Every new project introduces a new system in the pool. Once implemented, this system has to be "Owned" by the support team. Ownership of a new application always creates problems, especially if roles, responsibilities and alignments are not laid out earlier on.

2) Lack of knowledge around the application: Would you take up something you had little idea about? Why expect the support teams to behave otherwise?

3) Lack of expertise: Support teams usually are a constant in the organisation, while projects are many and varied. It may happen that the support team has limited expertise in the area and technology of the project.

Here's my 4 pointer on how to make Transition a (hopefully) simpler job:

1) Involve them early: Involve the Support team pretty early in the project. As early as the kick off meeting itself

2) Decide the support model early: This is the heart of the transition strategy. This is where it should be amply and crisply clear who does what. Lay down the RACI matrix clearly. Lay down the plan clearly. If the issue is technical, who resolves it? If there is a DB issue, who handles it? When the end user has a query, who clarifies it?

3) Decide the infrastructure requirements and work out the costs: Based on the support model, infrastrucure gets decided. Does the support team require any additional machines, specific software? Is there a requirement for DB? How will trainings be carried? Any costs for carrying out things remotely?

4) Plan and implement the transition process: Install the required infrastructure, create the crednetials, involve the support team through the phases of the project, plan for the training, and hand the project over.

Support transition can indeed be difficult, but just like the project itself, if this activity is well planned, support transition can be managed with comparatively less diffficulty.

The power of options

Project Managers tend to forget that being task master is not the only reason they have been hired for. A PM is hired also because he knows the domain in which the project operates, the culture and processes of the company, and can integrate all these elements together to deliver the project. Fundamentally, PMs are consultants to their projects too- someone who understands the gaps, finds options for it, and implements the option that best fits the goals of the company, project and the team members.

A lot of Project Management theories focus on the most common requirements a PM should have: Good Communication Skills, Negotiation Skills, Technical Know-how, Team Management and the likes. However, at the crux of all these 'everyday' activities lies the constant process of what I term the "understand-analyze-decide-implement" chain. As is pretty evident from the name, for any situation, a PM first understands the issue at hand, analyzes the possible options that can help resolve the situation, make a decesion/recommendation around the most feasible option, and finally, implement it.

There is great power in options. And these are the reasons why:

1) Options make you think: The whole process of determining options forces the PM to think about the situation, the project and the likes. Digging out options itself makes the PM sharp and aware of what may have gone wrong. Imagine a production issue in which, a DB is at fault. What will you do first?

2) Options are based on facts: Options can be determined only on the basis of clear facts. They help the stakeholders read between the lines and weed out things that are helpful, significant, but may not be obvious at the first sight.

3) Options build confidence that the PM is incharge: Possibly bigger than the solution itself, is the impression that the PM is in charge. Things have gone wrong, yes, but the PM knows his business. Presenting a list of well thought out options gives everyone the sense that a solution is soon on its way.

4) Options help validate the decesion: Most modern decesion making tools and techniques- the balanced score card, the solution matrix, distribution curves,and the likes- feed on options that are evaluated using the tool. This enables better decisions to be made, ones that are based on facts,data and well thought out analysis.

Options make life easy. They help reach decisions faster and effectively. Options are possibly the most important deliverable from the PM to the project-on the first day, the last day, and everyday. 

Taking up a Project that is in the middle of its timeline- understanding the IQ and EQ of a project

Far too often, Project Managers find themselves allocated to projects that are in the middle of delivery. Reasons for this are many- the previous project manager has resigned, taken ill, or simply been allocated to another project himself. Either way, the incoming Project Manager has a task at hand that is both uncomfortable and exciting. Every in-progress project has an IQ (Technical Story), and an EQ (people story to it).

How then, should the PM start this process of 'Getting in' this new project? Here's some suggestions to begin with:

1) Know the team members: Easier said than done, this is possibly the best way to start an in-progress project. Meeting with the team members in a free open discussion helps the incoming PM with a host of information items, including

a) The scope, business and the nature of the project
b) Project Status and pending items
c) Key stakeholders, ways of working, and,
d) Pain Points if any.

This helps understand the IQ of the project.

2) Understand the 'Context': Every project, at any stage, has a context, a story to it. Add to this the fact that a project requires change in leadership, and you have a good reason to know whats happened, more than whats going on. Speaking with some of the key team members to understand the reasons for exit of the PM, nuances of the business, technical and people issues, helps understand the Context better. The incoming PM also gets a good amount of clarity on the kind of trust (or the lack of it), if any, that exists in the project.

This helps understand the EQ of the project

3) Appoint a Shadow-PM: Regardless  of the context or status, a project still has to continue without interruption. Depending on the situation, an incoming PM may take time to fully settle in and start active work. In such an event, it is best to appoint someone from the team to take charge. Normally, it is either the outgoing PM himself, or, if thats not possible, then, a senior from the team or the most public member of the team who has built good relationships with stakeholders.

4) Stakeholder Plan:  Depending upon the complexity of the project, a plan should be established to speak with stakeholders beyond the immediate team. In the event that everyone is in the same site, the meetings can happen physically Face to face. For virtual teams, it is best to plan for conference calls. Remember, at this stage, only the plan needs to be established. The actual discussions happen later

5) Inform the stakeholders: The simplest, yet, possibly the most difficult piece of communication is announcing your arrival, to the stakeholders. After the first 4 steps have been done, close your arrival by informing stakeholders of the following. This, of course, assumes that the exit of the previous PM has been communicated before.

a) Your arrival.
b) Who handles the project until you 'fully' take over.
c)  Summarize your stakeholder plan, to inspire confidence, and clearly indicate you will set up calls and begin discussions with various members.

Using and Utilizing the Project Mlestone Plan to manage the project

The Project Milestone Plan is a very useful document, and that's a very generic understatement. Having said that, there is a difference between USAGE and UTILITY of a project plan. Amongst others, the most important ways to use a Project Plan lie in 2 aspects of Project Management:

1) Project Planing: Talk about Project Milestone Plan, and many multiple versions of a document jump to mind. There are various pieces of information that a Plan can contain, but its use in the early stages of the project happens well, when atleast the following information is captured on it:

                    a) Project Milestones and Activities laid out in as much detail as possible.

                    b) Clear Ownership of the activities

                    c) Atleast the start and End Dates for each activity. 

                    d) Comments section to lay out dependencies or status

2) Project Tracking: Well crafted and designed dashboards have been the Status Reporting norm in IT companies ever since one can remember. Such dashboards serve the dual purpose of project status reporting, and Risk mitigation. However, such a dashboard based system suffers from the need to be 'linked' to the approved project milestone plan. Essentially, this means that the milestone level dates of the plan are copied to this dashboard, and status is tracked against these copied items. An easier and more accurate way to track the status of the project hands-on, is to 'utilize' the milestone plan itself, and publish it to stakeholders weekly. Since the plan contains activities, dates and owners, it becomes very efficient to report status by way of comparing Actual v/s Planned Dates. Where the project lies today can be directly mentioned at the activity level. The comments section can report potential issues, risks in case of delay.And lastly, since owners are well identified, such reporting lays out the exact resource level dependencies or delays.

The Risks identified here can be tracked in a separate Risk Risk Register and the mitigation can be done on that document.

For most IT Projects, there is good enough reason to 'Utilize' a Project Milestone Plan to track the project accurately and easily. Good PMs realize the value of such plan based reporting to stakeholders.

Linkedin is so much more than just 'Linking'

Far too honestly, I hadn’t looked at Linkedin for reasons much beyond staying ‘connected’ or for the occasional job search. With the advent of social networking in the last half decade, here was a platform that had a PROFESSIONAL look and feel to it. A site that was meant for professionals to LINK to each other, explore their networks, for recruiters to find another medium to post jobs and the likes. As amazing and impressive as it was, I had some difficulty initially to fathom it.

Social networking is a skill and not many truly realize that. Every social network has a feature and purpose about it that make it different from the others. The whole general point of social networks though is that it enables someone to make sense of your person on the web. It helps people understand your hobbies, your activities, your associations, networks of friends, your choices, activities and so on. Advertisers are likely to pull up trends on your personal data on FB to post ‘customised’ or ‘sponsored’ ads. Your photos, checkins, status trends give much meaningful insights into what is likely to ’catch your attention’.

If FB is personal yet social, Twitter is primarily a way to get a real time idea of what you think about world events. Much real time news today is available on Twitter accurately and quickly than anywhere else. Google is hot as ever for search, mail and the ‘personal’ collaborative tools. The other sites enable you to manage people, google helps you manage yourself.

Somewhere in all of this lies the equally amazing linkedin. Equally because every other is; amazing i’ll tell you why. Linkedin has this amazing side feature “Interests”. One subpart of that is “Groups”. Without drawing parallels, I view Groups as a social network in itself. The Groups feature enables one to join a group of professionals of the same mix. For instance, as an IT PM, my most obvious choice for a group is a Project Manager’s group. A search for such a group lists out all such groups that exist in the Linkedin universe. Typically, this list is sorted in the descending order of group size, or in a way that places the most popular groups at the top.

Within a group is where the fun is. You are likely to meet a lot of people from all across the globe and who share similar interests. I am part of atleast 2 such PM groups. There are members that cut across lines of most parameters. The members are from all age groups, countries regions, even sectors!! Some members are veterans and some are recent graduates. The simply humongous variety of people that the groups features affords is itself awe inspiring.

And the best part of groups is the discussions. This feature allows members to post topics of discussions and others can contribute this by posting their opinions.  People from various sectors contribute their opinions to such topics of common interest, agree, sometimes quarrel even. As surprised as I was too understand just how much Risk Management meant in IT, I was more amazed to learn that Risk Management is an important aspect even in the consulting business!! The Project Charter that I know in IT is an integral component in any other industry too!! That the problems I encounter as PM in IT are shared by PMs in other, completely disparate industries too!

Linkedin has totally caught my attention now! Each discussion is a mini blog, an online learning in itself. This gives me the opportunity to express my views freely, interact with legends from industries, and at the end, learn real time. That’s one for being ‘Linked’