pmStudent

If you've done any work in systems or software development, you've probably use Lines of Code (LOC) before.

Either as an estimation tool with something like COCOMO, or as a retrospective gauge of the work your team did on a particular release of software with added/modified lines of code.

It's All Bull

Lines of Code as a measure of productivity or as an estimation tool is nearly meaningless. But it's something quantifyable and so people (especially managers) grab hold of it like a life raft.

I feel very similarly about Function Points, and I think both of these try to simplify something that is too complex for a one-size-fits-all method.

Here's the problem with equating LOC with productivity, effort, or estimates:

• An engineer may spend several hours on a block of code less than 20 lines, and the next day spend the same amount of time on writing 1000 lines of new code. Both are completely valid, and reality. It's all a matter of context.
• A system with 50k LOC that does the same thing as another system with 100k LOC is twice as good as the 100k LOC system, I'd argue. The lower LOC system is refactored better, less complexity for the same functionality, and easier to maintain.
• I re-wrote about 40 lines of code a few weeks ago (this is rare, I usually don't do much programming any more) because of a performance issue. The end result was half the code, and a roughly 450x improvement in performance (returning records in 400ms from a database instead of the ~3 minutes it was taking). I spent an hour reducing LOC to improve the system.

Now tell me how LOC can possibly be a global proxy for value or productivity?

User Stories or Features

I think the best proxy we have is user stories or features completed, provided and assuming they are valid. It's really just as valid a measure as any other arena like construction...you have assumptions that requirements were elicited properly and you are actually building what the customer wants.

What do you think? How do you measure or estimate productivity/effort on your software projects?

Taking small risks and failing fast is the best risk management strategy around.

Let me explain..

Vallidated Learning Through Small Risks

I identify strongly with the Lean Startup concept of validated learning, and I think every project is just like a startup. Especially in the beginning, validated learning is much more important than just cranking out a product for the sake of it.

If you think your customer will love something and you have the capability of demonstrating it in a visual way very quickly, do it!

The learning you gain from the experience, even if the customer hates it, is worth it.

Avoid Creating Your Own Big Risks

Too many project managers create their own large risk of producing a product no one will use.

That's the biggest risk of all.

Trying to avoid the small risks.  Being afraid to make mistakes. Being afraid to be wrong.

These are the attributes that result in big risks. And the project manager induces these herself.

What ways can you take small risks proactively to learn more quickly and avoid the big risks?

photo by Explore The Bruce

I'm a Mechanical Engineer having 4+ years of experience in engineering projects. In addition, I have 3+ years of SAP Project System experience. Presently I'm working as a SAP PS consultant. I want to expand my career in project management field.. Seek your guidance.... -Pratik

Pratik, it’s all about separating yourself from the pack.

Networking is powerful, because when people who know you are good refer you there is a trust factor that goes with it. Don’t just send your resume or CV and a cover letter. Make phone calls. Ask someone in the company what the big challenges they face are, and come up with a solution to them.

Find ways to demonstrate your ability to add value to the organization.

Stepping Stones

Project Controls may also be a good stepping stone into a role managing the type of projects you want to manage. In a role like project controller, scheduler, or coordinator you will gain experience of the 'other side' of projects from the technical side you already know.

Sometimes we are throwing items over the wall to another team even when we don't mean to.

Let me explain.

5 months ago, I set up several meetings with one of my teams and a team we interface with. We squared away exactly how things would work between our systems and the design changed slightly because of what we learned.

Yesterday, I found out we had a problem.

How Did This Happen?

Even though everyone reviewed the design and agreed it would work well, there was a tiny, weeny problem which unraveled the whole design.

We just caught it yesterday, because the other team got around to implementing their code and were having problems. After several discussions we got on the same page, and I slapped myself on the forehead.

I Should Have Known

It's true, I should have caught this fatal flaw in our design back then. But then I remembered my email signature:

"Mistakes are usually caused by flawed systems; not bad people."

So what is broken in this system that could have prevented this problem?

This is What

Instead of just agreeing on the design and assuming it would function properly, we should have worked closely with the other team to build a prototype. A minimum viable product (MVP) - we would have discovered at once this fatal flaw.

As Eric Reise discusses in the Lean Startup, validated learning is the key to a startup company's success. While we are not a startup, projects definitely fall into that category. Had I followed this approach and asked the teams to collaborate to produce an MVP to validate our design change, we could have avoided all this. We would have known about the problem within a few days and resolved it with a different design.

That process also would have been even more collaborative, treating our two teams as a single team instead of throwing some specs over the wall, which is essentially what happened. Even if we all agreed on the specs in full, we didn't know what we didn't know.

So that's my recent lesson learned. I'm going to go sulk in the corner for awhile. Leave a comment to cheer me up.

Photo by Jessicizer

I received a question from someone dealing with a discrepancy between how EVM reporting has been presenting progress versus actual progress.

Essentially, the scope and cost of the project has increased, partially through estimation problems and scope changes over time.

However, it appears they are still reporting against the same Performance Measurement Baseline (PMB).

The sooner you can transparently communicate with key stakeholders, the better. 

Josh,
Does re baseline mean:
Drop in progress percent complete, say reporting 80% in revised scenario versus previously reported 90%??
If not, then what does this rebaseline actually mean?

A rebaseline only happens when everyone agrees there has been a significant change in scope, cost, or schedule.