Feed: Project Management - AggScore: 40.0

Project Metrics

Recently a colleague said that most if not all of his projects were within budget. Is this the measure of a great project manager? Not so fast.

What about time and scope? Are all three components of the triple constraint: cost, time, and scope equal? Probably not. It is project specific.

For example I was managing a project that was going to be released to production on a predetermined release date with other enterprise applications. It would either go into this release on the specified date or it wouldn’t. The date was not negotiable and since the driving cost on this project was labor; cost was fixed but to a lesser extent than time. This left scope. This project involved incorporating changes and modifications from a third party vendor.  There were 14 changes from the vendor that made up this project. The majority of the time and cost of this project was spent testing these third party changes. It so happened that this vendor was the worst vendor that me or anyone else ever dealt with. Some of the things that they said were fixed were not fixed; in addition there was functionality that was working which was now broken. This vendor had some serious organizational problems. I was on the phone to them every day at 4:00 PM to see what could be resolved before our cutoff date. It was a priority not to make things any worse. In other words fixing the modifications that broke existing functionality had priority. When it came down to it I had to put a change request in to remove two of the 14 changes from the scope of the project.

My point in this is that the project was on time and within budget, but the scope was reduced.

On most if not all projects one point of the triangle (cost, time, and scope) will be fixed and any changes are made to one of the other points or both. There are projects where the scope is fixed and the sponsor is willing to adjust time or cost as long as the scope remains intact.

So given this, finishing a project within budget doesn’t necessarily mean the project was successful. What then is a measure of project success? How about the satisfaction of the project sponsor and stakeholders?
 

Manage Expectations

This is something that project managers hear a lot “You need to manage your client’s expectations.” However, when you think about it, you may wonder just what this really means. If you have requirements defined isn’t it reasonable to think that these are your client’s expectations for the project? Perhaps not.

You don’t know what is going on in your client’s mind and you may not have the requirements defined as well as you think. Maybe the requirements have areas where they are abstract, vague, or missing. These areas get filled in with what your client wants them to be or thinks they should be. This is happening on a subconscious level; it is normal for the human mind to fill in gaps.

So since it is unreasonable to read your client’s mind this is how you avoid unrealistic and incorrect expectations:

1. Document the requirements in detail and get signoff on them. Make it clear that what is not mentioned in the requirements document is not part of the project.
    
2. Communicate proactively and regularly. This is part of the status reporting process. This communication can alert you if expectations are getting out of line.
    
3. Follow a change management plan. This is part of the project management process. Your client needs to be informed of any changes and you need to make sure he adjusts his expectations accordingly.
    
4. Deliver against the requirements or the changed requirements. Doing so will meet your clients expectations.
    

Project Management Methodologies

Asking about project management methods can be a loaded question. This is because that while they may be referred to as project management methods, most of the time they are software development methods or SDLC (Software Development Lifecycle) methods. These methods can dictate to some extent how a project is managed.

If you were to search on project management methodologies you can easily find over 20. There is a lot of rebranding, that is to say someone takes a methodology that has been around for years, makes some minor changes, makes up some different terms and will say this method is better than the last best method. The person doing this can sell books, services, and get some speaking engagements. These are easy to recognize, the line is that this method is the method to end all methods (until the next one comes along). If you are not using this method then you are behind the times. In reality the methodology needs to fit the project and the organization.

I will cover some of the main methodologies:

Waterfall - The waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance. The Waterfall model is useful when the requirements are well know and can be completely documented before moving on to the next stage.

Iterative and Incremental Development -  Sometimes you might see these two terms separated. This is very useful when the requirements are not fully known or understood. A common example is an application where a new user interface needs to be designed. A business user may ask for something unrealistic like a web page with 50 columns across for entering data. There is no criticism meant when I say they can’t tell you what they want but they can tell you what they don’t want when they see it. To flush out these requirements you can provide mockups of web page designs. You can iteratively and incrementally develop each web page incorporating the client's input. This is not a new methodology, Yourdon wrote about it 30 years ago.

Critical Chain – This is a very interesting methodology suitably for a manufacturing environment. I have never seen this used in IT Project Management.

Agile – There has been so much written on this methodology that I won’t say any more except to have a look at the Iterative and Incremental Development methodology above. Remember what I said on rebranding.
 

Five Key Attributes of an Effective Project Manager

1. Knowledge and Awareness of Project Scope: There are several parts to this. One is the big picture project scope. This is what I like to see in the project charter. If it’s not in the project charter then I’ll put it there. Big picture scope goes like this: we are currently at Point A and we want to get to Point B. What does Point A look like? Hopefully this is easy to answer because this is where we are now; however be careful with assumptions. Point B is where we expect this project to get us. What does Point B look like? Don’t just answer this in physical terms such as application xyz is installed, but what does it mean in terms of stakeholder satisfaction? How does this bring value to the enterprise? The second part of this is the detailed project scope. Think of a circle, the project is everything inside the circle, everything outside the circle is “non-project”. Scope creep can eat a project alive.
    
2. Having both a Broad and a Narrow focus: A project manager needs to be aware of what is scheduled to happen next month because he probably has to do something now to make sure it happens. Some examples are ordering equipment, being aware of lead times, and arranging for future resources either in-house or contracted. A narrow focus is needed on events happening today or this week. What reports or documents need to be out this week, what is happening on the project that may need attention today?
    
3. Being able to influence without authority: Sure you have authority as a project manager, but do you really want to flex that muscle every time you need something? At times you need to but most other times you need to negotiate and work it out. You have resources assigned to your project but they are assigned at 50% does this mean you have them for four hours a day? I don’t think so. Realistically it means you have them 100% for a bit and then 0%. Now you need them back again, but another project manager needs them as well. How do you resolve this? You go and talk to the other manager and over 98% of the time you not only work it out but you have gained a favorable relationship with someone in the organization. 
    
4. Communication: Today more then ever we have global project teams. Different people may communicate differently. Be aware of this, make sure you understand and are understood. Some people are more sensitive then you might think, so keep your communications professional.
    
5. Leadership: If it comes down to it what your team needs is a project manager not a friend. This isn’t to say you can’t do both, but there will come a time where you have to draw a line. Don’t be afraid to assert yourself and make hard decisions.

How Industry Specific is IT Project Management?

IT Project Management is not very industry specific. I don’t know how many times I will get asked if I have managed projects in a particular industry because the person asking thinks that is the one important distinguishing selection factor for that position. Nothing could be further from the truth.

Project management knowledge, talent, and expertise is or should be the distinguishing selection factor. I have been doing this close to 15 years across many different industries. In each position I had to understand where the company was in their process maturity and work from there. Different industries presented minor nuances at the most.

Some managers think that they are reducing or controlling risk by hiring someone with their specific industry experience. This simply isn’t so. Any experienced project manager will say the same thing.

This is all well and good, but what do you do if you encounter such a situation? Sadly not much. It has been my experience that someone with that mindset doesn’t want to see things from a different perspective and there is nothing I know of that will change that mindset.