Posts Tagged ‘SDLC’

Nailing down requirements is the number one complaint of project managers. Addressing this requires two skills: political adroitness and finding a balance point between exploring solutions and exploiting what is known and available. I’d like to share some from a workshop I provide on decision-making in uncertainty.

Political Adroitness

A mantra regarding project requirements goes something like this,

“Requirements are stated needs, expectations are unstated needs. Clients tend to judge based on expectations.”

For example, a common retail experience is a customer picking a $20 pan from a display that includes $200 triple-clad pans. The expectation frequently is quality-by-association. As you might guess, the customer ends up disappointed because food cooks unevenly, burns, and sticks to the pan. They return to the store angry that misrepresentation occurred and they want their money back, at a minimum, or demand the $200 pan at no extra charge, at the extreme.

When something similar occurs on a project the best way to deal with it is by leaning into the situation as quickly as possible. The longer the expectation is held, the greater potential for damage in the relationship. Do this is by offering possible “straw” scopes. These are scopes that fit within the time and money parameters established and meant as much for example as anything else. This can take several iterations.

Initially, the goal is getting the client to see the expectations just don’t match the time, money, and resource limits established. In other words, see if they will shift their view and do it in such a way the relationship stays intact. When acceptance of the need to shift sets in, then drive towards THE scope that appears to work.

The reason “appears” is used is simple. The scope has yet to be drilled down to clear requirements that can be turned into specifications. Which leads to another aspect of political adroitness – working with the team.

The team needs to be involved in creating the scoping alternatives because they are the ones ultimately shouldering the responsibility. As you might have already guessed, having a good working relationship with team leads and subject matter experts is critical. If these relationships are absent team members can simply say the requirements aren’t clear, take a passive-aggressive position, and leave the project manager hanging.

The Explore/Exploit Balance

In complexity theory the above falls under the “explore/exploit balance.” This is where the risk comes into play. Typically, there is insufficient time to explore all options. On the flip side, the team may run into conflict and severe limitations if they dive in based on using what has worked in the past. The solution is best when the customer, project manager, and the team all share the risk. In other words a balance is needed; one that is optimal and spreads the benefits equally with the difficulties.

To recap, it isn’t enough to simply say the client should be realistic and not expect a $20 pan to perform like a $200 one. The PM and team need to push as far as they can working with the client in developing a realistic solution – one that will save reputations, relationships, and pocket books as well as produce the desired deliverable.

—

Tagged as: active garage, budget, center for change management, Change Managemnet, client, customer, expectations, gary monti, Money, Project Management, project manager, project reality check, Project teams, projects, Requirements game, scope, SDLC, time, triple constraints

A Simple Question: What is the goal of computer technology development in today’s marketplace?

Some will disagree, however my postulate is that technology development in today’s marketplace has the single goal to support business objectives. Without the satisfaction of business objectives, eventually there is no way to fund new development of the technology, and it becomes deprecated in the marketplace and falls into disuse (assembly language application development, dbaseII, basic programming, etc.).

New technologies bring about the following situations:

1. New products and the space to create new products.
2. Shortened time to market – new methods and tools usually focus on productivity improvements.
3. New methods of development, testing, deployment – minimizing the effort to develop, test, deploy and measure results.
4. Ability to attract and retain employees by offering interesting projects.

1. New products and the space to create new products are created by new technologies. 30 years ago, most development was done in simple languages that didn’t support modern concepts (Assembly, BASIC, COBOL, and FORTRAN). New concepts such as Object Oriented Design and Programming were a future glimmer, but unachievable with the technology of the time. While still used by segments of the engineering community (embedded systems, legacy code), development of those technologies has substantially slowed. Fast forward and we have systems now that are capable of programming themselves, indeed more and more engineers spend their time specifying work flows and behavior, less time “coding” directly, instead using code generators to process the specification into code for the computer to compile and run. Without these new technologies there would be no modern operating systems, few of the modern programming tools would be available and fewer still the programs that people use to operate their businesses.

2. Time to Market is of paramount importance in these days of worldwide competition. The facticity of the worldwide situation is that there are thousands of equally skilled developers that are spread across the world from Arkansas to Zimbabwe, with the ability to work on projects anywhere in the world.  Basic economics dictates the price for the services these engineers are able to offer; more developers will drive the price downward. For a project to be profitable it must be out in the marketplace and “tested” by the audience of users very quickly.  Missing the time to market window significantly increases the space for the competition to effectively compete, reducing the future possibilities available to exploit, an argument for established technology. Sending out defective software can have a similar effect, an argument for new technology.

3. New methods of development, testing, deployment minimize the effort to develop, test, deploy and measure results.  Newer tools provide for increases in both productivity and quality. Not so readily recognized is that new tools and higher productivity result in higher motivation among the development staff.  Getting “stuck” in old technology is a career dead end if you are unable to keep up with new tools and techniques.

4. Ability to attract and retain employees by offering interesting projects: If you are an employer, offering work that is based on old technology, highly skilled developers will recognize that the position is a dead-end from a technology or career standpoint.  This makes it difficult to attract highly skilled people. This translates as the need to hire lower skilled or otherwise less desirable employees.

Even more difficult to manage is the developers career’s concerns if the business is based on older technology.  Failure to care for that concern will result in employee concerns becoming threats (employees abandoning their positions for new positions).

The downside to staying with old technology for too long is that is a dead-end path.  The facility provided by the language will quickly be outpaced and the development path will be limited by the structure available from the tools.

On the other hand, jumping from technology to technology without completing the business objective raises costs and prevents the satisfaction of the business concerns.

A fine line must be drawn and closely managed with respect to the usage of technology in the business environment.

As with most things it will depend on the business objectives and constraints.

Tagged as: ActiveGarage, Entrepren, Entrepreneurship, Innovation, Leadership, new products, product development, SDLC, Software development life cycle, technology