Requirements are tools not weapons

Consider these requirements; · The system shall properly calculate the taxes due at the time of payment. · The system shall properly display the location and speed of inbound projectiles. · All users will only be able to change data appropriate to their role. They are a clear example of poor communication and are likely…

1

Fighting the Fear, Uncertainty, and Doubt

There are a few reoccurring themes in project recovery;  Hold Fast, Don’t Flinch, Lead calmly, and of course the old stand by … decide slowly but act quickly.  Troubled projects are ripe with Fear Uncertainty and Doubt (affectionately known as FUD).  Our job, like it or not, isn’t just creating and delivering a solution but…

0

It’s just software …

It’s just software … really, it’s just software.  It’s not as important as your family, or your health.  It (generally) doesn’t kill people or change lives.  That kind of thing is left to real people.  I will concede that those real people may be using software to help them kill people or change lives but…

0

Agile versus Formal modeling

In response to a recent discussion over at Yahoo on the requirements Engineering list, a question was posed as to why “just enough” was ever okay when creating a model.  After all incomplete models or improper use of a modeling standard has to be bad… right?  I believe there is another perspective on modeling to…

1

A risk-reward scale for evaluating project practices

So you’re seeking to improve things. You tried to implement a “best practice” or twelve … how did that work for you? I am convinced that problems addressed by a well known practice will not always result in a well known and positive result, and it seems I am not alone.  In a survey of…

1

There are no right answers.

All troubled projects share one and only one characteristic.  Things have gone wrong.  Terribly wrong.  Other than that, everything is, and I contend must be, unique.  Let’s face facts here; projects are the accumulated work of people.  No amount of consistent process can ensure individuals with unique personalities, under unique conditions, will do the same…

1

What’s your projects risk tolerance?

Risk tolerance is defined on investopedia as the degree of uncertainty that an investor can handle in regard to a negative change in the value of his or her portfolio. Sounds pretty good to me for project portfolios too.  In our case, negative change includes concrete things like expenditures that fail to return expected value…

1

Introducing Project Practice Portfolios

In a recent paper, Bridge Methods: Using a Balanced Project Practice Portfolio to Integrate Agile and Formal Process Methodologies, my co-author and I dug into how nearly every methodology, be it formal or agile, allows if not requires customization to the set practices used throughout the software development lifecycle (SDLC).  We call the collection of…

1

3 Problems that prevent delivery

Here are a few random problems that prevents delivery of a solution to users that they can use.  Remember, if it fails to function as intended, fails to function at all, or fails to return a reliably correct result it’s not done.  You have problems. 1. Fixing the wrong problem.  An organization that has been…

1

5 things that make a problem worth fixing

At it’s heart, recovery is about fixing problems.  Before we get into individual and combination problems let me lay my definition on the table for your consideration and comment.  A problem is only a problem if it causes the team to underperform.  Underperformance is determined by plotting the teams current performance at any moment in…

1