requirements

I received the below great question a few days after my Art of War for Product Managers and High-Performing Professionals.  I thought you might be interested in the answer as well. What if two product manager colleagues disagree on something and can only agree to disagree and cannot come to a resolution, what do you [...]

This week we will take a short-cut into slapping ourselves back on the path. We won’t spend time investigating why and what took us off our course. Instead, we will jump into action with the idea of “doing one scary thing a day” to help keep up moving forward at a faster pace.

Most everyone is familiar with Pro and Con lists to help make a decision. Often times the Pro and Con List does very little to clarify the decision – because – well – the reason you are creating the Pro/Con list is because it was a ‘close call’ to begin with. We don’t go to the trouble of making a Pro and Con list on ‘no-brainers’. Often times the pro and cons are pretty equal – making the decision still difficult. Our mistake is that we stop at this point. We don’t take the next step to reduce the impact of the “Cons”.

If I ever hear “Well – could you make a baby in one month with nine mothers?” again – I will scream.  Personally, I average four months per baby with my preemie twins.  Because designing is so costly, looking for twin opportunities – more often called “design re-use” – is a very sensible plan. In [...]

When is an Agile development effort not so agile?  When you haven’t clearly defined the ultimate objective.  I freely admit that I am not an expert in Agile development so my expectations may not be appropriate but come on now how can one expect to be successful if they don’t know what the ultimate goal [...]

The new PMBOK(R) Guide has a new process called Identify Stakeholders. As a person invloved with creating PMP(R) Exam study materials as well as developing and delivering PM courseware, I always want to keep my material up-to-date with the latest PMBOK(R) Guide.  Of course, this means searching for practical examples from organizations and real applications.  [...]

Good Requirement Management is perhaps the most important factor in many projects’ successes or failures.  Some research had mentioned that it can be as high as 65%.   Requirement specification greatly affects the scope of the project, which in turn affects the resource and time required.  In this blog, I will share my thoughts and [...]

Have you ever worked for someone who said ALL requirements are high priority ? Yeah ! We all have. Customers often are insistent upon the delivery of a certain feature set by a certain timeline that may seem impossible to meet. If everything is high priority, nothing is ! Project teams often bear of the brunt of this indecisiveness. Impossible targets, [...]

That requirements will change is a given. How you plan for and manage that change is crucial. Think about what you want to accomplish with your change management, what you want to protect yourself from, what you want to avoid, and then put in place the practice that makes sense for you. Having a tool [...]

There is a set of SW practices that I consider non-negotiable, and they begin with 2 that are requirements-related: 1. Written, reviewed, approved requirements 2. A requirements baseline, implemented with a requirements management (RM) tool In my last company, getting these done in a way that was accepted by engineers and management alike did require [...]

At my last company we took pride in the amount of work we were able to accomplish with a very small team – software of high quality and releases on tight schedules. The high quality and the responsiveness to customers’ demand for new features kept our customer support expenses low and gave us good customer [...]

I was listening to an NPR talk show segment about customer service last week.  It was mainly about being on hold, the friendliness (or unfriendliness) of the support givers, etc.  There was a quote from a customer service person who said that they were rude because the customer service expense “sucked out whatever profit they [...]

By Josh Nankivel Fellow blogger Craig Brown over at Better Projects asked “Why reverse engineer requirements?” in a recent post.Interesting question: Craig asked what value there is in trying to derive requirements based on an existing system. There are two points that came to mind on this.

How many times have we been brought in to rescue a project, and we find out that the engineers had started work without really taking the time to define what success looks like? Here’s a lesson on thinking before you act from a recent police blotter from my neighborhood. Yes, it’s a true story.

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 [...]

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 [...]

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 [...]

The programming press and IT journals are full of stories about the failure of software outsourcing. The statistics are sobering. Less than 50% of outsourcing meets financial objectives. The outsourcing of many business processes besides software development also has the same less-than-stellar results. Forrester reports the top three causes of outsourcing failure are:

In my examples this week, I’ve been writing about ways to convince those with the power to embrace some good software project management behavior.  I’d like to give some final advice for the week.  Think like a leader. Don’t simply complain about your project management problems.  Try to do something about them.

I just loved the latest grievance from my students (see Monday/Tuesday/Thursday posts).  When being given more work than schedule to accomplish it, or additional tasks on top of their “primary” assignment, upon replying that they were going to have to slip something, that they couldn’t get it all done on schedule, they were told by [...]

A second complaint from my students (see yesterday’s post) is: “Management adds requirements to my project without asking me if I can still make the schedule and without taking anything away.  All the time.” Of course, what’s “bad” about this behavior is not that requirements change: that’s expected: although there must be a limit.  What’s [...]