Requirements

Defining requirements

Problem solving relies on what came before and what will come after

Sometimes it is not just what you do but the order in which you do it that matters. You absolutely must develop an ability to see several layers of consequences ahead of the solution as well as several layers of cause and effect behind the problem and then juggle them at once in the way … Read more

Requirements gathering the first big mistake.

Many seasoned project managers will start off a project by sending out his business analysis team to carry out requirement gathering.
Sometimes this is the right thing to do, in particular you should do this when you have a successful proven process that you want to automate using IT. Requirement gathering then educates the IT people responsible for system design (the features) on what they need to achieve.

This is a different scenario

Delivering benefits is no longer about getting a system signed off

(Who’s minding the shop?) This blog is an attempt to stimulate discussion and understanding of the balance of responsibility for delivering business benefits from IT investment. It is now fairly widely recognised that this is not as simple as choosing a system, getting it working and reaping the benefits, but as yet we can call … Read more

Getting the mountain to Mohammed

Few IT professionals have any grasp of the difficulty facing a business person who needs to stay abreast of tough competitors and try to win competitive advantage via IT without understanding how IT works sufficiently to make the right decisions.
Few people in business have any appreciation of exactly how complex and demanding a job it is to ask them what they want, give it to them and get a “thank you, that was great.”

Managing requirement scope

Sometimes the definition of requirements and management of their delivery is described as Scope management.  Scope management is composed of five distinct phases: Scope initiation Scope planning Scope definition Scope verification Scope change control Scope initiation refers to the justification phase. This is when a Product management team create Market requirements and Product requirements documents … Read more

Requirements engineering strategy can make or break your project .

Part one – What would you like sir Part two – Requirements,tests, training, help files Part three – Why no project exists in isolation-what should be done Part four – Business rules, Process rules, Process, Data, different viewpoints Part five – Testing requirements is not optional Part six  -Requirements strategy can make or break your project If … Read more

Testing requirements is not optional

Part one – What would you like sir Part two – Requirements,tests, training, help files Part three – Why no project exists onin isolation-whwat should be done Part four – Business rules, Process rules, Process, Data, different viewpoints Part five – Testing requirements is not optional Part six  -Requirements strategy can make or break your project Yes … Read more

Why no project should exist in isolation and what needs to be done

Part one – What would you like sir Part two – Requirements,tests, training, help files Part three – Why no project exists onin isolation-what should be done Part four – Business rules, Process rules, Process, Data, different viewpoints Part five – Testing requirements is not optional Part six  -Requirements strategy can make or break your project How … Read more

Requirements, tests, training, help files – the connection?

If you began with a vague idea and kept changing things in the hope that you would eventually end up knowing what you wanted, then success is about as easy to find as the end of a rainbow.

Delivering the right project

Really! – Have you seen this new stuff?
This could easily have been Mick Jagger and Keith Richards after their first successful gig. In the modern world, it is more likely to be a hard working CTO talking to a COO about his systems needs

Business rules, Process rules, Process, Data, different viewpoints on requirements.

To fully understand requirements it is necessary to break them down and consider each on it’s own merit. First of all requirements come from different viewpoints and these angles must be fully considered.
The key viewpoints to consider are: Business rules, Processes, Process rules, Data rules and models, Operating environment internal and external, Culture, Skills, Adaptability.

Agile, Agile the rumblings continue. .

Your perception of agile is not right, you just don’t see the real benefits of agile because you are not a true agile practitioner, you just use it as a looser form waterfall when it suits you, but you never really took the faith. We are delivering year in and year out in a way we never could with a traditional approach.

About the author

Edward Taaffe has a 10 year record of achievement in project and Programme management in both the private and public sectors ranging from negotiating with local authorities to use centralised shared services to introducing ground breaking technology to government and convincing them of the benefits of early adoption. Previously and interspersed with this, he has … Read more