Working on IT Projects of the Future

According to Gartner, IT departments in 2012 will look fundamentally different to the IT departments we work in now.

The analyst company has predicted that an IT department will add four new roles to the team in the coming years.  None of them are specifically project related but they all have an impact on the way in which we manage IT projects.

The roles are:

• Litigation support manager
• Enterprise information architect
• Digital archivist
• Business information manager.

Read more »

Productive Laziness and the ‘Open Door’ policy

I’m all for being there for people, honest I am. It’s just that people take advantage of it if I am.

So for the ‘productive lazy’ project manager I would suggest that it is perfectly acceptable for the lights to be on and for no-one to be at home; not all of the time obviously, and at critical times access and visibility are all too important. But for the rest of the time, why not let the whole of the team work a few things out for themselves, take some degree of responsibility and decision making, and generally get on with the tasks at hand.

Being there when you are really needed and being there all the time are very different things indeed.

Being reachable in a controlled manner, and within an acceptable timeframe, to answer appropriate questions (and not stupid ones) is equally important. The last thing you want is a long line of people queuing up at your desk waiting to ask advice, and you phone flashing with an ever increasing number of messages, all the time whilst you inbox is reaching capacity with incoming demands for your attention.

This can lead to the ‘lights on all the time’ syndrome, a very dangerous condition:

‘What should I do now?’

‘Breath’ you might reply

‘In or out?’

You have so many other more useful things that you could be doing, like reading a good book in the comfy chair for example.

Applying the ‘Productive Lazy’ approach

Avoid the swamp

This is linked in so many ways to the communication topic already covered. If you create a communication plan that guarantees to swamp you from day one, what is the benefit; to you or to the project?

None!

The plan should ensure you are not seen as the oracle for all matters, nor that you are the bottleneck for a constructive information flow within the project team. Most projects develop communication plans in a certain way; that is as a plan that is the documented strategy for getting the right information to the right people at the right time. We all know that each stakeholder has different requirements for information and so the plan defines what, how and how often communications should be made. What project managers rarely do is consider and map all communication flows, official, unofficial, developmental or complete, and do a load analysis across the project structure of these communication flows. Of they did they would spot bottlenecks much earlier on that they normally do, usually this is only identified when one part of the communication chain starts complaining about their workload.

Consider the open door policy

The ‘open door’ policy has become a real management cliché.

‘Of course’ managers pronounce in a firm voice’ my door is always open to you all, day or night; I’m really there for you’.

Empowerment in this way has become more an entitlement for the project team than a project manager’s choice; they just expect you to be there when they want you to be (and not even when they need you to be there either). An ‘open door’ policy can easily transform a project manager’s role from that of an authority, and managing, figure to that of a subservient accommodator with little chance for exercising control on those that demand access to them.

Be a good manager

The best manager is the probably the one who reads the paper or MSN every morning, has time enough to say ‘hi’ at the coffee machine, is isn’t always running flat out because they are ‘late for an important meeting’. By that I mean that a good (an obviously ‘productively lazy’) manager has everything running smoothly enough that they have time to read the paper or MSN and so on. This is a manager who has to be confident in their position and capabilities.

A good manager will have time for their project team, and being one who has everything running smoothly, will allow that to happen.

A good manager does not to be on hand twenty four hours a day, seven days a week. They do not have to have the answer to every question nor do they have to be the conduit to the answer to every question. There is a whole project team out there – go talk to some of them – they probably will have a much better answer to hand anyway.

Think about number one

You honestly want the best for yourself as well as for the project; I understand that, so give yourself that chance. Have you ever met a project manager who has put themselves down as a project risk? ‘Yeah, well I am just too nice a guy, can’t say no, can’t turn someone away, love to chat’ – likelihood 80%, impact 100%, mitigate now!

But hopefully by now you also want to apply the productive lazy approach so consider this; let the team deal with 80% of the communication, 80% of the questions, 80% of the issues, and let the 20% come through you for consideration and guidance. You don’t even have to ‘solve’ that 20%, I would further suggest that only 20% of this 20% are likely to be answered by yourself in an adequate manner, there are always others that can better advice.

Think about the rest

OK, you have dealt with the ‘thinking about number one’ thing, now what about your team? Well by dealing with ‘number one’ you will have already done the team a huge favour. You will be accessible when you need to be accessible. The lights will go on as and when they are really needed – it is a kind of ‘green’ project management policy.

The worse thing that can happen is that just at the moment when there is a ‘clear and present’ need for someone to speak to you, whether that be on a project or on a personal matter, you are just too tied up with a whole pile of nothing to even give them the time of day. Remember the whole ‘respect’ and ‘reputation for team support’ team thing we spoke about earlier, well this is a major contributor the that.

Analyse and reduce

And this is not a one off action; you need to keep on top of this as well. Projects change, communications develop, and roles flux. Do a quick analysis of what information and queries flow through you, and how and regularly re-assess. Can others deal with some of this? What are the important components that you should be involved in? Are there too many questions and communication from certain sources? And so on.

Make sure that everyone knows that the lights will go on and when and how they can turn that light on fast if they really need to.

A project manager’s tale about the importance of position

This one is not my tale; it is the story of a friend of mine, a friend who is, of course, a project manager. A project manager who I know to be very good at team building, a real ‘people’ person.

Picture a new project with a new project office. Apparently the company my friend was working for had reserved some brand new office space in a building that they were going to move other departments in to in the coming months. In the meantime the project team could take over one floor.

Now, I have been in many project offices over the years ranging from a single desk to a temporary office unit (grey boxes that get lifted in to place by a crane and officially described as ‘relocatable and modular accommodation’ apparently). But, by all accounts, this new building that my friend moved in to with his project team was superb.

He chose a nice new desk by a window and with a view facing the doors so that he could see all that went on, people coming and going, working (or not working I guess), and so on.

And so life was good and thus did the project move forwards in a pleasing way.

The only feature that was lacking was a decent coffee machine. They had a temporary one to begin with but the team waited with baited breath for the new, top of the range, super-dooper, hot beverage dispenser.

It arrived one week day morning, wheeled in on a trolley barrow. My friend was elsewhere at the time on important project business. When he arrived back in the project office he was somewhat surprised to see that his desk now had a new neighbour. A coffee machine.

‘Hey, grab a coffee, its great’ was the general cry from the project team. I am sure that that is what he did, before walking the two feet back to his desk.

The project office was full now and so it was too late to move desk. Oh well, a great project office with a great coffee machine was not something to make too much fuss about.

And then things went downhill:

Day 1 – People started saying ‘hello’ each time they lined up for a coffee at the machine by his desk.

Day 2 – People started conversations as they waited for their freshly simulated brewed cup of java by his desk.

Day 3 – People started sitting on his desk, whilst they waited for coffee, said ‘hello’, engaged in conversation and were generally sociable.

Day 4 – People asked him where the spare coffee cups were and what ‘error 54g’ was.

Day 5 – People asked him what the telephone number for the coffee repairman was so that they could report ‘error 54g’ and get the coffee machine fixed.

Day 10 – People started using the phone on his desk whilst waiting for a coffee etc.

Day 15 – The project manager left the building.

In actual fact he did move desks, he manage to secure a small space across the landing from the main project office. It wasn’t ideal as he was now removed from the project team but, on balance, it was better than the alternative.

It doesn’t matter that you want to run an ‘open door’ policy in order to be as accessible to everyone, if your want to get on with your job you do need some ‘space’. To be right at the centre of everything all of the time is not conducive to being a good project manager.

It was the coffee machine or the project manager, and the team made it clear that the coffee machine won hands down!

A final comment

So for the ‘productive lazy’ project manager it is perfectly acceptable for the lights to be on and for no-one to be at home; not all of the time obviously, and at critical times access and visibility are all too important. But for the rest of the time, why not let your project team work a few things out for themselves, take some degree of responsibility and decision making, and generally get on with the tasks at hand.

Being there when you are really needed and being there all the time are very different things indeed.

‘You never know till you try to reach them how accessible men are; but you must approach each man by the right door’. Henry Ward Beecher

Estimating the Project

Most of what I’ve written so far assumes that the project manager is usually in a situation where Sales has closed a deal for a project and the information is passed on to the Professional Services portion of the organization for execution. The project manager is assumed – unfortunately – to have little to no input into the estimation/sales portion of the project and he or she basically gets what they get. That would be in terms of negotiated resource hours, dollars/budget, and the statement of work (SOW).

Jason Charvat writes, in his book “Project Management Nation,” about the estimation process form the PM perspective – this would coincide with the type of work I performed earlier in my career where all high-level requirements gathering, estimating, pricing and negotiating the engagement with the internal business sponsor (these were all internal projects at a major corporation) rested on my shoulder. Talk about control…I loved it. Here is Mr. Charvat’s section from his book – this covers what he calls the estimation process.

The Estimation Process

The project manager should remember that the estimation that results from the planning phase is not final and is considered a temporary estimate. Once more detailed project planning is performed and the project costs and WBS schedules are fine-tuned, a more accurate estimate emerges. Basically, the estimation process has a few primary steps:

• Develop the WBS.
• Estimate each part of the WBS constituting the total project.
• Schedule the work according to each WBS task.
• Determine the resources needed, quantities, and availability.
• Obtain the latest resource rates, including next salary reviews and increases.
• Determine the level of effort needed to complete each WBS task.

Something that is very important during the estimation process is that project managers ask the client to pay a price that is relevant to the perceived value of what they receive. If the client is willing to pay for the project, the project manager needs to determine whether it is profitable enough to do the work. To determine this, project managers must determine cost. This is where the estimation is needed.

What to Include in a Project Estimate

• Internal labor or cost of employees – Burdened cost to company—benefits included
• Hardware costs – Servers, printers, workstations
• Software and licensing – Application software, downloaded software patches, code
• Travel and accommodation – Airfares, hotel, tolls, gas
• Administrative support costs – Personnel, finance, and legal support
• Training costs – User training, computer-based training, lesson plans
• System documentation costs – Manuals, policy & procedures, on-line documentation
• Stationary costs – Project stationary
• Infrastructure costs – Office space, desks, rent, parking

Estimating the Effort

It is said that you cannot manage what you cannot measure. No matter what project a project manager has been allocated or assigned too, the project estimate should include the following:

• Size of the project
• Resources required
• Project duration
• Costs needed to complete the project, labor, hardware, travel, etc.

Estimates in the IT industries are incredibly difficult to complete due to so many unknowns. The initial estimate is, in many ways, the most important. The initial estimate will be a focal point with which the project manager can compare all future estimates. Because of this, there are several recommended steps to follow when achieving an initial estimate.

• Break down the project requirements as far as possible to subsystem levels (WBS).
• For each WBS element, identify its similarities with previously developed projects and use this historical data.
• For those WBS element units not strongly related to previous IT projects, use SMEs to estimate the size of those elements needed.
• Form the size estimate for the entire project by rolling up the estimates for all the WBS elements.
• From historical data and expertise, estimate the level of effort.
• Divide the size estimate by the work rate to obtain an estimate of the effort in work hours.

Once the WBS has been developed, many project managers move directly to determining the duration of the task. This is normally done using a software tool, and it visually appears as though the project manager is on the right track. This is not the correct approach; it creates room for errors and bad planning. Remember that it takes a lot of skill and experience to estimate all WBS tasks. For example, it can take one seasoned IT architect a few hours to do a server capacity assessment, but the same task could take two junior IT architects double the amount of time to perform.

Similarly, a situation may arise where only one person can do a specific task, such as cloning a server. Only one resource can do the specific task, not two. Therefore, in this case, the emphasis is on ensuring that the resource is best-qualified to perform this task. The project manager also needs to discuss the issue with an SME to determine the amount of effort. The cost per task is directly related to the resources and effort needed. The project manager must accommodate the level of effort needed to perform the task.

Attributes of a Successful Project Manager – Part 1

In this three-part series, I’ll present Jason Charvat’s take on the attributes of a project manager as documented in his book “Project Management Nation: Tools, Techniques, and Goals for the New and Practicing IT Project Manager.

This basically another take or view on the two articles I’ve previously posted on this topic:

• The Characteristics of a Project Manager (that evolved into several parts)
• The Skill Set of the Project Manager – Another View (derived primarily from Gary Heerkens’ book)

ATTRIBUTES OF A PROJECT MANAGER

For about three years as a project manager, I failed to listen to my team members and came across as arrogant. The one thing I learned from experience is that right action gets right results and wrong action gets wrong results. This kept driving me compulsively to consider what attributes I needed to possess if I ever was going to be an outstanding project manager.

Project management, as a profession, has changed through the years and has produced many good project managers who have risen to higher levels, consulted world-wide, and often started their own organizations due to their broader understanding of business principles. Within the project management profession, a manager quickly becomes well-known in a very short period of time; clients identify those project managers who are good and those who cannot perform well. The following personal attributes demonstrate the profile of a good project manager:

• Self-confident
• Problem solver
• Good listener
• Able to gain the respect of the team
• An effective communicator
• Capable of reacting dynamically and making decisions quickly
• Considered a professional
• A team player
• Knowledgeable about project management

Project management consultants are normally distinguishable from other company managers by the following attributes:

1. Reputation. The project manager is well-known by name in his or her industry and is often called upon to deliver papers, case studies, and new concepts to this audience.
2. Experience. The project manager has sufficient experience and has completed many projects.
3. Leadership. The project manager possesses the necessary leadership skills to lead people.
4. Presentation skills. The project manager has the ability to communicate on all levels in order to inform about project status.
5. Expertise. A project manager is normally employed because he or she is an expert on the subject and can speak with confidence on any project discipline.
6. Professionalism. The project manager, who belongs to reputable project organizations, abides by a code of ethics specifically designed for the project profession, thus ensuring that clients, organizations, and society are able to entrust project managers with their daily duties.

In Part 2, we’ll further discuss other areas of knowledge and abilities that the project manager must possess to successfully lead IT projects.

SaaS Aids IT Project Management in Washington

Sourced from Government Technology

Prioritizing IT projects proposed by various agencies within a local government sometimes can make IT leaders into villains — especially by the agencies assigned lower spots in the pecking order.

But the IT staff in Tacoma, Wash., found a way to avoid that trap. They deployed “on-demand IT governance” software to automate the analysis of what the city’s IT staff could realistically finish over the course of a month. Based on that analysis, agency representatives then vote each month on the Tacoma IT Department’s priorities. This enables IT priorities to come from the end-users themselves, rather than what could be construed as arbitrary judgments of IT officials.

“We’re making decisions based on facts and data as opposed to emotion and organizational norms,” said Bradd Busick, manager of change management for Tacoma.

Each month, after agencies electronically submit their project requests, the city’s IT staff enter the project descriptions into software from Innotas. The software analyzes how labor intensive each project is in relation to the city’s limited IT resources. The software then gives order-of-priority options on which the agencies vote. For example, the software might report that if the city made a Human Resources Department project its No.1 priority, the IT staff would only have enough workers and time remaining to also complete the water department’s project that month.

By contrast, if agencies voted to push the HR project to the following month, IT employees would have enough time and resources to complete five other projects that aren’t as time consuming during the month at hand. The HR representative would need to make a strong case to the other departments that his or her department’s project was worth putting off other departments’ priorities until the following month. IT employees sit relaxed on the sidelines and use the set of priorities the vote produces. If agencies decide later that they don’t like the list of priorities, they have their own judgment to blame, not that of the IT staff.

“There is always a bit of mystery to what happens behind the closed doors of IT. This lifts the veil and shows that if we have only 85 IT people, we can only do ‘X’ amount of work,” Busick said.

An agency submits its project using Innotas software and can later use the software to observe a project’s progress in real time. The software also calculates the amount of work IT employees have done for various agencies over a given period of time.

“They’re able to see that last month, for example, 25 percent of the work we did was for the power utility,” Busick remarked. “If you’re an agency that is paying for IT, you want to know how much they’re working for you.”

Innotas is a software-as-a-service product, meaning the vendor hosts it and delivers the application through the Web. “From a cost perspective, it makes a lot of sense for a government because we don’t have to host any hardware onsite,” Busick explained.

The city paid Innotas a $50,000 one-time fee for 150 employees to use the software.

Busick said he has noticed an increase in the number of projects his team has been able to complete since deploying on-demand IT governance. And fewer errors have occurred. Busick expects to have calculations showing those improvements in September.

Read the story here.