Successful repetition of any business activity can lead to a false sense of security. We often assume that just because something has worked in the past, it will always work in the future. Adrian Reed looks at what we can learn from the Great Train Robbery and how selective perception affects us.
Adrian Reed is a consulting lead business analyst and principal consultant and director at Blackmetric Business Solutions, where he helps organizations solve their pressing problems. Adrian also speaks internationally, trains, and consults on business analysis and business change-related topics. Read his blog at adrianreed.co.uk.
All Stories by Adrian Reed
The discussion of the relationship between the project manager (PM) and the business analyst (BA) is quite common, and some see a natural career path from senior BA to PM. The BA and PM roles are complementary—and there may be similar shared competencies—but there is a very different focus.
Requirement prioritization can be a difficult exercise. Stakeholders often insist that every requirement is essential, and prioritizing requirements can feel like asking them to part with their most treasured personal possessions. Adrian Reed offers three ideas for making prioritization easier.
Enterprise analysis focuses on achieving a solid understanding of the problem or opportunity and the business and customer value that the organization hopes to achieve. An important part of enterprise analysis is acting as a critical friend when stakeholders can't see beyond the silver packaging.
A common way of approaching business and project goal setting is to use the SMART technique (Specific, Measurable, Achievable, Realistic, and Time-bounded), but is it smart enough? Adrian Reed explores a personal goal setting technique, PECSAW, to attempt to answer that question.
The distinction between project failure and business failure is slight—one can very easily lead to the other. One way to help avoid the downstream issues on any project is to ensure that sufficient project management and business analysis resources are assigned.
Is it advisable to define a system by stating what it shouldn’t do, or should “negatively-framed” requirements be avoided?