QSM will be hosting a new free advice column for software professionals who seek help to solve project management, communication and general software project issues. The first few scenarios are based on questions we receive all the time. Carol Dekkers is a QSM consultant and IT measurement and project management expert who speaks internationally on topics related to software development. Send your questions to Ask Carol!
I’m a systems analyst working for a telecom company and I have several projects on the go at the same time. Our PMO (Project Management Office) told us that now we have to start tracking the size of our projects both at the beginning and at the end. I can’t believe this – it’s just more metrics and (redundant) data. I already track project size because I do time reporting (by project) and all they need to do is add up my hours at the end and voila, you’ve got the project size: the more hours it took - the bigger the project. They don’t seem to get it and I’ve asked for an exemption from this overhead task. Their response was to enroll me in a two day sizing course! What can I do to prove to them that they already have the size because I keep track of my hours?
- Frustrated in Seattle
I can understand your frustration with your PMO – especially when it seems like you are being asked to collect metrics that have no purpose or context. Project size and work effort are two completely different constructs – they are related, but different, and I’ll tell you why. You are correct that your time tracking provides you with the number of hours you worked on the project – that’s a valuable measure and I applaud that you are doing this diligently. I also agree that the longer a project takes to do, the bigger it likely is – but not necessarily so. Some projects by their nature are more difficult, complex, and labor intensive and it becomes difficult to compare projects purely on the basis of effort. What your PMO is likely trying to do is to track the relative “productivity” or efficiency of the project – which they derive by dividing the output of a process to the input to get a ratio. This is done in a lot of different industries even though it is new in IT. We’ll talk about that in a minute, but first here are some examples:
- In the automotive industry, the efficiency of a car is measured using MPG (Miles per Gallon);
- In the construction industry, costs are compared based on $ per square foot (buildings) or $ per mile (bridges and roads);
- In global economics, countries are compared based on Gross Domestic Product per Capita;
- In agriculture, farm production is compared on the basis of bushels (of wheat) per acre;
- There are many more examples.
In IT, one goal of the Project Management Office is to find efficiencies across projects based on comparing $ input per size output or hours effort input per size output. Your work effort hours are the input variable in the equation and the project size is the output. Depending on the type of project you are doing and what artifacts or work products are available, there are a variety of sizing methods that may be used. If you are doing software development work, there are various options to measure the size:
- Function Points (FP): these measure the functional size of the software you deliver based on what the software does (business processes)
- RICE Objects: (R)eports, (I)interfaces, (C)onversions, (E) nhancements are a second way of counting functional size
- Source Lines of Code (SLOC): the number of delivered, non-comment lines of code (specific to a programming language)
- Implementation Units: a unit-less number that measures the size of the software
If your project is hardware specific or does not involve software “development” (such as doing a maintenance release or operating system upgrade/install), then the size of your project will be measured differently.
Regardless, Frustrated, when several projects are compared on the basis of say, $ per FP ($ to produce 1FP) or SLOC per hour, the PMO gains insight into what methods, tools, etc. used in the project processes are most efficient. Sometimes it is hard to figure out what is the best combination of tools or methods unless you can compare across projects (similar to comparing car performance on the basis of MPG.)
I hope that you do attend the sizing workshop and participate in the measurement initiative. No matter what, in project management, project size does matter! The more information you can glean from your various projects, the better your projects should become. In fact, when you have measurement information at hand, it becomes easier to get new tools and try newer more efficient methods of doing your project.