It’s more important than ever for software organizations to build a healthy engineering culture. Healthy cultures rally developers around common goals: shipping high-quality work, continuously improving, and having fun in the process. Your culture is key to recruiting and retaining the talent you need to ship exceptional customer experiences.

 

Step one is get knowledge, step two: redesign for effectiveness then, lastly, step three, pull in IT. It is to start from a base of knowing what IT can do to support a more effective design, the costs of development drop to tens of thousands and everything developed gets used – an amazing feat in IT development. And the benefits delivered by the IT system are significant: Real-time visibility of the work, accurate information about demand and activity times, costs and materials employed.

Corporate mergers and acquisitions (M&A) continue as a critical means for enterprises to meet strategic objectives such as growing market share or acquiring new capabilities. However, rate of successful outcomes has not grown at the same pace as the number or M&As themselves. In this post, Dr. Coghill argues the case for using enterprise architecture to provide increased visibility and clarity around M&A objectives to support improved outcomes. 

Learning about mental models and how to apply them to their work is one of the best investments for business analysts interested in achieving the level of deep thinking that leads to better outcomes for their projects and organizations.  There is incredible power in using inversion at the outset of a project to imagine ourselves in a future where the solution has not only been delivered, but is in the hands of end-users to get their job done. Rather than simply going through the typical project phases in forward motion, we can then look backward and gain additional perspective into what might go wrong so that preventive steps can be taken to avoid those bad outcomes.

Several years ago I was looking for examples using the generalization / specialization technique with use cases. They are not easier to find. And they are typically limited to a use case diagram like the two below. This article provides examples of both the diagrams and the scenarios for a future gas station business.

Have you heard of agile business analyst? Does this even make sense? Agile is to move quickly. How can a business analyst move quickly when (s)he is loaded with effort of understanding the scope, collecting, analyzing, and defining requirements, convincing and negotiating with stakeholders, make a technical team understand the requirements and ensure delivery as committed?

In Part 1 of this series John Seddon argued that Agile, as practiced, is bereft of knowledge, hence its ubiquitous failure. Here he argues that ‘get knowledge’ is the starting-place for effective change.

Part 2: Knowledge: the prerequisite for profound change

It may seem heretical to suggest that we make change without knowledge, but, as Deming pointed out, experience is not equivalent to knowledge; you can spend 20 years in an organisation without knowing how to change it for the better. Leaders, clients and stakeholders describe requirements or problems to solve on the basis of their current world view, governed by information from their current control systems, but what if their world view is flawed? What if there are bigger and different problems to solve?

Five S can be applied in any work environment and prepares a work area for a follow-on Lean process improvement effort. In this case, 5S prepares my garage for Lean process improvement in doing home activities like automobile maintenance, appliance repair, and hobbies like gardening and woodworking. But, remember the preparation benefit is only realized if 5S is sustained. As I said I am the worst (ugly) in keeping the “new world order” in my garage.

The intention of these viewpoints is to make it easier to see and understand the real business problem. This article focuses on the fourth viewpoint, the Future-How, which looks at the solution to the business problem. It does this by assessing alternatives, and then choosing the best solution to that real business problem.

For business analysts working in an environment where there is a gap between SMEs and the delivery of an IT-based solution for business needs, requirements are documented to bridge that gap. You are reading this because you are a business analyst responsible for documenting detailed requirements and, in the case of this article, business needs involving one or more user interfaces (UIs) or reports.

The objective of this article is to answer the question, “How much detail is necessary?” Spoiler alert – quite a bit. This is to avoid, as much as possible, a BA having to go back to a SME when designers or developers have business-level questions about a UI or report. Or worse – designers or developers not asking questions. Instead, making assumptions about what the business needs and proceeding to deliver the solution based on those assumptions.

Business rules cover a very broad space. Across the entire space, however, you can be sure about one central idea – business logic should not be buried in procedural programming languages. Call it rule independence.  Why is rule independence important to you? Because rules entangled in procedural code won’t ever be agile. Rules change all the time – and in a digital world the pace of change is always accelerating. How you can stay on top of it is the central question in business agility.

If we look at the previously proposed process end to end, it starts with the customer journey. The journey is mapped to the internal business processes, systems, and data sources. For both the customer facing and internal parts of the journey user stories are created to document the gaps between the as-is and to-be states - effectively form the backlog for the change. For each story, acceptance criteria are prepared in a way that enforces the expected behaviour in the system. Ideally, those should be the scenarios that are likely to appear on the real life journeys and not the hypothetical future scenarios. These scenarios when implemented and tested feed back to the journey and underlying layers changing them as the new functionality is introduced.

This question has been asked several times before, and various answers have been advanced to settle this matter. A short answer is ‘Yes’. But, unfortunately, this answer is not good enough to the ‘naysayers’, who think a business analyst has no place in Agile teams.  To answer this question in a long way, we have to take the bull by its horns and talk about the elephant in the room. This article is an attempt to contribute to this ongoing debate. Whether you agree with me or not (as I tackle this elephant in the room), the truth is - this argument is apposite and has to be had.

Learning about mental models and how to apply them to their work is one of the best investments for business analysts interested in achieving the level of deep thinking that leads to better outcomes for their projects and organizations. The first article in this series described what mental models are and talked about the first mental model covered, second order thinking. In this second installment we discuss another mental model that that can help business analysts become better problem solvers: integrative thinking.

Requirements documents are used to communicate the aims of a project in a clear, concise way to ensure all stakeholders are on the same page.  When we talk about a requirements document we are often referring to a Business Requirements Document - or a BRD.  But as well as a BRD, there are 9 other types of requirements documents that a business may want to use while pushing a project through its stages of completion. The type of format to be used depends on the result of the project itself, whether it’s a product, service or system, and the particular requirements it has.