The Scope Baseline

I’m studying for the PMP exam, and I’m using the PMPrepcast to study. I actually found one point to disagree with Cornelius Fitchner on today! (That doesn’t usually happen!)

In the Scope Control podcast, he talks about the “updates to the scope baseline” as being redundant, since the process also produces updates to all 3 components that make up the scope baseline:
(more…)

Cutting to the Chase on Organizational Maturity

Jim Sloane is a particularly adept person to provide an executive primer on organizational project management maturity.  There are a multitude of models and approaches for measuring organization maturity and the associated business benefits.  With the increasing number of tools and models available to organizations, it can be challenging to choose the best strategy that will work for YOUR organization. (more…)

An unrepeatable success?

Back in the very old days (early 80’s), I was on a team (of 24, I think) that delivered a successful software system on time, on budget, and with every feature the customer had requested.  The schedule had been tight, 18 months from inception to use, as I recall. 

This happened right in the middle of the “software crisis”, when failure after failure plagued the industry, especially on government projects.

After the balloons and toasts to our success, our management wanted us to tell them why we had succeeded so that they could try to apply these lessons to future projects (and bids). (more…)

Saying No

Saying “no” is hard for everyone.

“If I say “no”, they will think I’m not a team player.”
“If I say “no”, they will think I’m not committed to the product’s (company’s) success.”
“If I say “no”, they will blame me for the other project’s failure (because I wouldn’t let my resource spend some time helping it).”
“If I say “no”, they will be disappointed in me.”
“If I say “no”, they will say that I’m inflexible.”
“If I say “no”, they will say that my team isn’t willing to work hard.”
“If I say “no”, they will be mad at me.”

And no one likes people to be mad at them. (more…)

Some thoughts on usage scenarios

Recent posts on the importance of usage scenarios (use cases or user stories) in the development process warmed my heart.  In my experience, scenarios are perhaps the single most valuable practice in the process.  Scenarios help clarify requirements for everyone, ensuring that the ultimate user knows what they’re getting, guiding the developer, and forming the basis of tests for the quality and test engineer.

When I was doing research for course material, I noticed some concerns published in IEEE Software about how to handle usage scenarios in requirement documents.  Specifically, the author was voicing concerns about how to handle them in traceability matrices.  I personally think it’s a non-issue, and I thought I’d spend a minute saying why. (more…)

An Outsourcing Progress Report

I’ve written somewhat negatively about outsourcing in the past – primarily issuing warnings about doing it without proper planning, for the wrong reasons, or with expectations set too high.

Recently, someone close to me has had his own outsourcing experience.  Software that he and his group would normally develop was being done by a group of software engineers in India.  Since there were in-house developers available to do the work, the decision to outsource doesn’t seem to have been driven by a need to offload anyone’s work. 
(more…)

PLC Implementation: A Case Study (Part 2)

Ok, we have performed a number of interviews and town hall meetings at all levels of the company, evaluated the company culture, and elected to develop a PLC.   Now we need to define our implementation and get the job done.

Implementation:  Based on the feedback (more…)