Entries for December 2007

45054 Views
29 Likes
1 Comments

I have a hypothesis I want to explore:

Requirements Risk management could be a useful approach to requirements analysis, and lead to better requirements management.

High level the idea goes like this:

  • Risk management is an important part of project management
  • Requirements management is also a critical part of the puzzle
  • Should we be running a requirements risk management process on our projects?

The purpose of this article is to introduce the topic of Requirements risk into the Requirements Management discussion. Feedback and commentary is welcome and can be provided at ModernAnalyst.com

Serious projects run risk management processes throughout their lifecycle. In fact, risk management is one of the nine knowledge areas of the PMI’s PMBOK, and one of several key processes in the (British) OGC’s P3M3 project, programme and portfolio management framework.

PM bodies obviously take risk management seriously, and it’s backed up by the academics. Studies are showing that a structured approach to risk management has a correlation with successful project delivery. Risk management is a vitally important part of project management.

I don’t need to explain the problem of requirements again. There are plenty of articles on the web about how poor project requirements management costs billions of dollars and lead to disappointment everywhere. Of course the best way to manage requirements is to put trained and experienced people on the job. Building up the knowledge areas and processes will also support the need to improve requirements management.

Author: Craig Brown
Craig Brown works as a Project Manager and Business Analyst.  He is an active contributor to Modern Analyst and runs his own blog called Better Projects.

3657 Views
1 Likes
0 Comments
Requirements Simulation is a technique used to visually define and model business, user and technical requirements. The value proposition of most tools in the marketplace today is to bridge the communication gap between business and IT by empowering the Business Analyst to completely, and clearly define application requirements. Since specialized ...
14014 Views
6 Likes
0 Comments

"Good specifications will improve programmer productivity far better than any programming tool or technique."
- Bryce's Law

INTRODUCTION

In terms of systems development, during the 1960's and early 1970's you were either a Systems Analyst or a Programmer. Period. At the time, there were substantially more analysts than programmers (at least a 2:1 ratio). This was due, in part, to the fact that computing was just coming into its own in the corporate world and there were still people around who could look at systems in its entirety. However, there was a screaming need for people to program computers and, as such, this became the boom years of programming. If you knew COBOL, Fortran, or PL/1 you could just about right your own ticket. Salaries were good, and you could intimidate your employer simply by what you knew (you had to commit something like murder to get fired). The emphasis on programming became so great that authors rushed out voluminous books to increase programmer productivity, hence the birth of the Structured Programming movement of the late 1970's, which was followed shortly thereafter by the CASE movement (Computer Aided Software Engineering).

Author: Tim Bryce

5266 Views
0 Likes
0 Comments

Business analysis is about more than software development. It can help business leaders to understand the business and develop resourcing, training and IT strategies. Through careful analysis of workflows and business processes you can identify opportunities for increasing efficiency and profitability. You can use business analysis techniques to help you identify potential processing bottlenecks or under-utilisation of costly resources.

Author: Jenny Blinman

6342 Views
0 Likes
0 Comments

Business analysts go by many titles one of them being Management Consultant.  In this article, Tony Jacowski talks about the management consulting career.

Author: Tony Jacowski

6519 Views
1 Likes
0 Comments
In the first two installments of this series, we saw why BPMN is important to the Business Process Expert and got an overview of the notation. In this part, we’ll look beyond the spec to suggest some best practices for making your BPMN models most effective. The art of effective process modeling depends on what you are trying to do. Unlike traditi...
5299 Views
0 Likes
0 Comments
In the first installment of this series, we saw why BPMN is important to the Business Process Expert. In this part, we’ll look at the notation itself. In BPMN there are only three first-class diagram elements, or flow objects:  Activity, a rounded rectangle, representing work performed in the process  Gateway, a diamond, r...
5984 Views
1 Likes
0 Comments
Business process management (BPM) is an emerging discipline that looks at the enterprise in a radically new way. Instead of trying to automate and optimize individual functional units, like sales, supply chain, and customer service, in isolation, BPM views your company from the perspective of end-to-end cross-functional processes – exactly the way ...
27153 Views
16 Likes
2 Comments
What Is A Functional Specification? Functional specifications (functional specs), in the end, are the blueprint for how you want a particular web project or application to look and work. It details what the finished product will do, how a user will interact with it, and what it will look like. By creating a blueprint of the product first, time an...




Latest Articles

What Does a Technical Business analyst do?
Feb 17, 2019
0 Comments
The function of a technical business analyst is to bridge between business and technical teams. This can be undertaken in various forms. First, the br...

Featured Digital Library Resources 
Copyright 2006-2019 by Modern Analyst Media LLC