GovernIT

Today has been a good “thinking” day for me so far. First, I read a great post by Peter Kratzman on Mending Wall: Matches and Mismatches in IT stakeholder expectations

Then I got to watch this great interview of Gartner’s Daryl Plummer on Youtube

While I agree and understand Business’ frustration with IT, there are a few things that make IT behave the way it does. It cannot be a coincidence that most IT shops behave this way, right?

Some thoughts:

• Do Less with More – Supporting the same or increasing number of applications with less personnel, less money, outsourcing headaches, at a time when costs are going up is forcing IT to think about survival and not about innovation! If you are firefighting everyday, where is the time to think long-term?
• Technology Innovation and Adoption cycles don’t match – While new mobile platforms can come up quickly, supporting them in the Enterprise is a nightmare with untried devices
• Security Risks are discounted – with the qualification that the discount is valid till a breach occurs. For example, giving mobile support to Enterprise applications seems the way to go, but supporting Blackberry, iPhone and Android phones increases security risks manifold. There is very less experience out there on how to do it safely. Social Media, Cloud Computing/SaaS,  Data Storage are some other examples where security breaches can cost the company dearly
• Business still does not want to “own” decisions concerning IT. Moving to the cloud vs staying in-house is not IT’s sole responsibility. After all, if IT systems are down, the Enterprise is down!. In short, Business must move away from the “Get IT done somehow and don’t tell me about it” (pun intended!) mindset
• Like Business, IT has some processes and while they can be flexible, there are some constraints. Everyone has to live with constraints these days, so why be unreasonable only towards IT?
• Finally, the most important thing (at least, it seems that way to me) – the thinking that IT is a magical system that can bend however needed while Business processes are fixed in stone must be changed. I am reminded of my teacher in school, who admonished me – It can be done as long as the doer is someone else. When you have to do something, you get all the problems in the world!

So, who will bell the cat? (That’s just a saying, don’t take it literally folks)

IT. We must do a better job at communicating these to the Business. Much has been said about how to align IT with Business, but how should this alignment happen? Some case studies are listed here.

• Houghton Mifflin Harcourt’s CIO does a good job of Governance in this CIO.com article
• This CIO’s team congregates to discuss every business project that has an IT component (I like that) – Read here
• This paper from SAP America discusses the challenges and offers some solutions (Needs free registration) – Link here

I wrote some shorter posts on this here and here last year, but this seems to be a perennial subject.

Do you have other things in defense of IT? Or are you, perhaps, from the Business? Me, you ask? I believe in this quote (I have quoted this earlier too on this blog):

None of you are in IT; all of you are in business.

-Andy Kyte, vice president and Gartner fellow

   Send article as PDF   

This blog is usually a mouthpiece for my ramblings, but sometimes it is good to simply listen to others. I found out that MSDN had a radio channel and considering that Kanban is the new black, this is a good interview of 3 lean/kanban guys. Exciting folks to follow!

   Send article as PDF   

For those of you who celebrated Thanksgiving last week, here’s hoping you had a blast. For those of you who did not, well, have a nice week

I was reading Josh Nankivel’s How to be a Project Manager in 5 steps and was reminded of the time a team lead who had about 7-8 years of experience, came to me and asked the same question “I want to become a Project Manager, but need more experience. What can I do now?”

Of course, I did not have Josh’s post to point to then, so I gave him some suggestions on what he could do in the next 6 months and sent him on his way. I thought I would share them with you, just in case you have the same question. Oh, and he had another question immediately after his first, “Do you think I can become one?” The answer, dear reader, must wait until you have become one!

Okay, here are some things I told him he could do to gain more visibility and experience, while working on getting the formal education/certification. [My friend could do these things on a smaller scale since he was responsible for development tasks of a portion of the project]

1. Scoping, WBS and Change management

I know, these 3 are related but distinct areas, but the reason I grouped them is that these are related to understanding what needs to be completed and managing that till the end. I was not referring to the entire Requirements Management discipline here, but only understanding the boundaries of what was assigned, breaking them into smaller chunks and managing those chunks carefully.

We often see that once we start design and implementation, there are items that come up due to ambiguity in the specs and we start “interpreting” them. These can potentially become scope creep and hence needs to be watched carefully.

2. Estimation and validation of estimates

The team was asked to go through the assigned work and produce an estimate of time and effort to complete them. My friend was an experienced person and hence could quickly see if some piece of work was underestimated or padded up. Although, he had been doing this for some time, it was until later that he realized that tracking completion against estimates actually gave him more insight into accuracy of estimates.

3. Schedule planning and tracking

Historically, the project manager took the WBS and estimates given by the individual teams and prepared the schedule, which was then distributed back to the teams. In this case, I advised my friend to prepare a detailed schedule and send it with the WBS and estimates. This would enable him to see how much work could be allotted to different people with different capabilities and capacities, how to sequence task, how to adjust for early/late completion of tasks etc.

4. Reporting of project status

The project manager usually had a weekly meeting with all team members and compiled a status report based on different parameters. My friend could do the same – he can simply take the standard status report template and fill it based on his team’s inputs, add his own inputs/suggestions and send it to the project manager. You are right. This is what I suggested to him.

5. Identifying and tracking risks

The risk meeting was a chore to be done and after all, it was a PM’s responsibility. Moreover, the risks were generic and carried forward from project to project!

Of course, there were many things, especially at a technical level, that my friend cautioned his PM about – delay in procurement of the test bed for one week could push back the schedule by 2-3 weeks, licensing issues, less time for reviews or inspections could jeopardize quality of the work being produced etc, but these were mostly watercooler discussions. I suggested that he make this a little formal by entering it into the risk tracker the project had, so that it was interesting and valuable to the project!

I cheated a bit early on in this post – there is another one, but that’s because it is not just relevant to Project Management, but in any work stream. Maintain a personal journal: record every analysis that you made, every decision that you made along with the possible alternatives and record why you chose that, record every mistake you or your team made and why, record how the project manager handled a problem. The single most effective tool to learn something is to learn, try, introspect and learn.

If you were in my place, what would you have said? Better advise? Wisecracks?

Psst: If you are a wannabe Project Manager, read the Zombie series by Derek Huether or if you are contemplating a career move, start with this by Josh

One more Psst: The answer to the question “Do you think I can become one?” is another question, “Can you think of two things simultaneously while talking about a third thing confidently?” If yes, then…See ya

   Send article as PDF   

In the last post, we saw one of two things we should do for communicating and gaining agreement on your Metrics Definition. This week, we will look at something that even experienced people leap over – gaining agreement on the details of collection and presentation.

[Oh and if you are looking at an approach for defining Real Metrics, look no further than the Goal-Question-Metrics approach. You don't need to look further than How Do You Know Your Metrics Are Worth It by Derek Huether]

Standard Templates

I can’t stress this enough. Without standard templates for capturing, reporting and presenting, you will be firefighting every reporting period. Period.

Capturing raw data: Have a standard template in a spreadsheet or a tool to capture data as activities are being performed. For example, if you are going to collect information on bugs, use a bug-tracking tool for the entire Defect resolution process. This will get you the information much faster.

Capturing aggregate data: Once you have defined the granularity at which your data is going to be represented, have a standard template for aggregating the raw data into this. For example, if you are planning to capture helpdesk calls and have some categories for the types of help desk calls (hardware, OS, Standard software installation, network, email etc), aggregate the data for each type into this template for the current reporting period. Be sure to keep this information in some sort of a Document control system – this is the heart of your reporting system!

Presenting data: Create a standard presentation template with dummy data and create charts using the dummy data. Play around with different chart types until you are comfortable with the presentation. Most people don’t think about this much and are left wondering why the chart does not show the one point which the audience should notice. There is a wealth of information on the internet and elsewhere on the presentation of data (think Edward Burke), so I’ll not go over it now.

Tip 1: A good resource to determine which chart type suits your data best is at http://chartchooser.juiceanalytics.com

Tip 2: Have a standard template where people can enter data, but cannot edit the charts themselves. People do try to gloss over bad information by using “tricks” such as changing the axis’ values etc. If you have an honest organization, feel free to ignore this!)

When you are finished with creating the standard presentation with dummy data, make sure you drive it by the key stakeholders – those who are going to produce this information and those who will consume this information. Most of the arguments during presentations are around the representation of the information – how it gives incorrect/incomplete picture, the axis values not starting with zero, colors/fonts not being consistent etc. So, ensure you have buy-in on this part so that people focus on the content subsequently.

Bonus Tip: Automate your templates as much as possible, if you are not using a tool. It makes everyone’s life that much easier. Initially, you will spend a lot of time fixing problems with the automation, but believe me, it saves a lot of pain later.

I have tried to crystallize my learning around getting your metrics accepted and implemented. What has worked for you? Do you have any specific templates/resources that has helped you in getting the numbers out? Share with me below in the comments.

   Send article as PDF   

I was reading a great article from Harwinder of Deep Fried Brain on 20 Common Project Risk Management Terms Explained. The other two terms that are quite important in the risk Management domain are Risk Probability and Risk Impact.

These are usually quantitative and provide guidance on correctly prioritizing risks (and therefore allocating the planned contingency budgets). One other term that I usually recommend when talking about Risk is “Risk Clarity Date” – a term I use to describe the possible date when more information about the risk becomes known to re-evaluate it.

Typically, projects look at the Risk log every x weeks to go through all the risks and figure out if something needs to be changed – this is not very realistic, since many risks are either time-based or event-based.

For example, if there is a Risk that a software component being developed will not be on time, but this is not going to change unless more information on the actual progress is available.

How do you do risk management? At Project levels only or do you have a Enterprise-wide Risk Management process? Share with us.

   Send article as PDF