What are Stakeholder Requirements?

Introduction

Recently I have seen much discussion around the term “stakeholder requirements”. To make sense of this I have looked into the origin of the term and the related terms “(stakeholder) needs” and “system requirements”. I am particularly concerned as the authors of the INCOSE Needs and Requirements Manual have chosen to interpret the stakeholder requirements in a way that is counter to all my experience in over thirty years of practice, consulting, and teaching.

Where do the terms come from?

Much of the terminology around requirements originated in the software world. One of the first lessons I learnt in writing specifications was to distinguish between the “user requirements”, which defined what users wanted, and the “functional specification”, which defined what the software (system) would do. Over time, these terms were replaced by “stakeholder requirements” as a way of recognizing that people and actors other than the users would have requirements on the system, and “system requirements” to recognize the importance of non-functional aspects¹.

Moving on in time, the two major standards in our field are ISO 15288 Systems and software engineering — System life cycle processes and ISO 29148 Systems and software engineering — Life cycle processes — Requirements engineering. Interestingly, neither of these standards explicitly defines “needs”, “stakeholder requirements”, or “system requirements”. Unless otherwise stated, the definitions here are from ISO 29148, though these are consistent with ISO 15288:

requirement

statement which translates or expresses a need and its associated constraints and
conditions

Note 1 to entry: Requirements exist at different levels in the system structure.

Note 2 to entry: A requirement is an expression of one or more particular needs in a very specific, precise and unambiguous manner.

Note 3 to entry: A requirement always relates to a system, software or service, or other item of interest.

stakeholder requirements specification

structured collection of the requirements [characteristics, context, concepts, constraints and priorities] of the stakeholder and the relationship to the external environment

Although neither standard explicitly defines stakeholder needs or stakeholder requirements, ISO 15288 includes this statement, which I have structured for consistency with other definitions:

Stakeholder needs

describe the needs, wants, desires, expectations and perceived constraints of identified stakeholders.

In terms of process, ISO 29148 states:

Defining requirements begins with stakeholder needs (or goals, or objectives) that are refined and evolve before arriving as valid stakeholder requirements.

This implies that goals or objectives can be needs and is consistent with the definition extracted from ISO 15288.

So, what are Stakeholder Requirements? ISO 15288 defines the process of defining them as (in part):

It analyzes and transforms these needs into a common set of stakeholder requirements that express the intended interaction the system will have with its operational environment and that are the reference against which each resulting operational capability is validated. The stakeholder requirements are defined considering the context of the system of interest with the interoperating systems and enabling systems.

Further, from this and the definition of stakeholder requirements specification in ISO 15288, we can infer the following definition:

stakeholder requirements

requirements of one or more stakeholders that express the intended interaction the system will have with its operational environment, and are the reference against which each resulting operational capability is validated.

We also need to define system requirements. ISO 15288 states this:

system requirements specification

structured collection of the requirements [functions, performance, design constraints, and other attributes] for the system and its operational environments and external interfaces

ISO 15288 further defines the System requirements definition process as:

This process creates a set of measurable system requirements that specify, from the supplier’s perspective, what characteristics, attributes, and functional and performance requirements the system is to possess, in order to satisfy stakeholder requirements. As far as constraints permit, the requirements should not imply any specific implementation.

It is then straightforward to infer the following definition:

system requirements

specify, in a way that is measurable, from the supplier’s perspective, what characteristics, attributes, and functional and performance requirements the system is to possess, in order to satisfy stakeholder requirements. As far as constraints permit, the requirements should not imply any specific implementation.

If we are to use the terms “stakeholder needs”, “stakeholder requirements”, and “system requirements” (and there is value in doing so), then it makes sense for them to mean different things. Defining stakeholder requirements as stakeholder-owned system requirements does not add any meaning, as you should be specifying the owner(s) as an attribute to each requirement anyway. Far better would be to separate them according to the definitions given above. We can use:

• Stakeholder Needs: The original set of statements from the stakeholders, poorly formed, ambiguous, and conflicting though they might be. Define the problem to be solved in its original form.

• Stakeholder Requirements: Derived from the Needs, a self-consistent, unambiguous set of statements that comprehensively define what the system must achieve. Owned by the stakeholders in the sense that they are the final arbiters. The problem to be solved after refinement, including resolving inconsistencies, filling gaps, removing ambiguity, etc. In other words, a well-formed definition of the problem.

• System Requirements: A well-formed definition of what any system must do to satisfy the Stakeholder Requirements. Derived from the Stakeholder Requirements, a self-consistent, unambiguous set of statements that comprehensively define what the system must do. Owned by the systems engineers.

The definitions I use above are consistent with decades of practice, ISO 29148, ISO 15288, and the 4th edition of the handbook. If INCOSE is now choosing to define stakeholder requirements as stakeholder-owned system requirements rather than as the problem definition, then it is taking a huge risk by removing an essential concept.

The controversy

There is nothing too controversial in the above. However, ISO 29148 states the following:

"When the system of interest is a system element at the second or lower level in the overall system structure, it is also necessary to identify stakeholder needs and requirements at that level. These needs do not just apply to the topmost system in the system structure. There could be additional stakeholders that are not discovered until lower level architecture or design decisions are made.

The stakeholder-owned system requirements are then transformed into lower level system element requirements for the system-of-interest."

The authors of the INCOSE Needs and Requirements Manual chose to interpret this as follows:

“To avoid ambiguity, whenever the phrase “stakeholder or customer requirements” is used in this Manual, the reader should assume what is meant is “stakeholder-owned or customer-owned system requirements”. This distinction is important in that “stakeholder, user, or customer needs” represent a stakeholder, user, or customer perspective of what they need the SOI to do while the “stakeholder-owned”, “user-owned”, or “customer-owned” system requirements are a different perspective that communicates what the stakeholders, users, or customers require the SOI to do to meet their needs. In this context, the stakeholder-owned, user-owned, or customer-owned system requirements are transformed from the stakeholder needs, user needs, or customer needs. Often, the requirements from the customer included in a contract with a supplier are “customer-owned system requirements”.”

To my mind, this interpretation is based on a fundamental misreading (or perhaps it would be kinder to call it an over-interpretation) of the quoted material from ISO 29148, as that document clearly uses the term “stakeholder-owned system requirements” in a very specific and limited way that definitely does not cover the full meaning generally ascribed to “stakeholder requirements”. Specifically, ISO 29148 does not state that the stakeholder needs and requirements identified at lower levels are system requirements. Indeed, the use of “stakeholder needs” clearly implies a transformation to stakeholder requirements following the stakeholder requirements process.

A reminder, as I wrote earlier, ISO 29148 also states:

• Defining requirements begins with stakeholder needs (or goals, or objectives) that are refined and evolve before arriving as valid stakeholder requirements.

The whole point of the statement is that stakeholder needs evolve to become stakeholder requirements. In other words, they are two clearly different things that effectively represent advances in the maturity of (information about) the system of interest. It is also clear from this that stakeholder requirements are not, as the NRM has it, a subset of system requirements. If they were, then the processes would be “Stakeholder needs definition process” and “Stakeholder and System [System/Software] Requirements definition process” instead of “Stakeholder needs and requirements definition process” and “System [System/Software] Requirements definition process”.

The authors of the manual are using the term “stakeholder needs” to mean what has traditionally been called “stakeholder requirements” and using “stakeholder requirements” to define a specific subset of system requirements, again going against decades of usage. Such a drastic and unnecessary change in terminology, particularly changing the meaning of a well-understood term, is potentially catastrophic and one wonders how a profession that prides itself on removing ambiguity can have allowed this to happen.

Discussion

The following discussion is based on responses given by one of the authors of Needs and Requirements Manual, Lou Wheatcraft, and me to posts on LinkedIn. I have annotated Lou Wheatcraft’s material with [LW] and mine with [KC]. I have used Lou’s material verbatim, but in some cases have edited mine for clarity.

[LW]: the phrase comes from ISO 29148.

[KC] I guess the phrase you are referring to is “stakeholder requirements”? ISO 29148 defines these as being at the business operational level, which is not the case for system requirements. It also states:

“The Stakeholder Requirements Specification (StRS) describes the organization’s motivation for why the system is being developed or changed, defines processes and policies/rules under which the system is used and documents the top-level requirements from the stakeholders’ perspective including expressing needs of users/operators/maintainers as derived from the context of use in a specific, precise and unambiguous manner. In the context described in the BRS, the StRS describes how the organization will utilize the system as a means to contribute to the business.”

In other words, Stakeholder Requirements state the problem and the context within which it must be solved. If stakeholder requirements were just system requirements owned by stakeholders, the standards would define them as such. But that is not the case. Neither ISO 15288 nor ISO 29148 define stakeholder requirements in that way. This definition is a clear misinterpretation of what ISO 29148 states.

The definitions I use are consistent with both ISO 29148 and ISO 15288.

[LW] My interpretation is not the same as yours. I do not find it useful for me to define and manage two sets of requirements communicating the same perspective when one is all that is needed.

[KC] Although you can consider needs and stakeholder requirements as addressing the same perspective, it is better to think of needs as the draft and stakeholder requirements as the published material. Same perspective, different degrees of maturity.

[LW] I must clearly define and understand the well-formed integrated set of needs and get them baselined and agreed to. This defines the scope of the project. Then I will transform those needs into a well-formed set of system design input requirements to which I will verify the design and realized SOI against. I will, or the customer will, then validate that the verified system meets the integrated set of needs.

[KC] I don’t disagree with this. But I do disagree with the use of well-understood terminology to mean something different from what most practitioners are used to. This would be like deciding to change the meaning of strain from force per unit area to force² per unit area.

[LW] I am not trapped in the “That’s how we have always done it” argument. If I can find a more practical and effective way, I will do it, even if not per any outdated standards that may exist, especially when those standards are not accepted not practiced by all organizations involved in product development.

[KC] I agree with this, except the last clause. It is fair to say that very few standards are accepted and practised by all organizations involved in product development. However, although not all the hundreds of organizations I have worked with over the years have used the term “stakeholder requirements”, none of them has ever used it in the way the Needs and Requirements Manual does.

[LW] In advancing the state of art, we sometimes must be willing to move forward and not be held back by the past.

[KC] Also true, but this is a clear case of taking a sledgehammer and destroying a useful, nay, vital, piece of existing terminology for absolutely no benefit.

Conclusion

I cannot agree with the usage by the authors of the manual. If we accept that usage, then there is no difference between stakeholder requirements and system requirements except that the former are owned by stakeholders (and the latter have no defined owner). If this is the case, then there is no need to have separate processes to define them, yet both ISO 15288 and ISO 29148 do have distinct processes for each.

There is no valid reason to change the definition of a term that has been in use for decades. Such a change will only cause confusion and, in this case at least, provides no benefit whatsoever.

Written with StackEdit.

---

1. One of the ironies of a typical functional specification was that the non-functional requirements section was bigger than the functional requirements section. ↩︎

Process debt and Workflow

What’s going on?

How often have you completed a piece of work but were not sure of the next step, or who needs to work on it next? Or you are yourself not clear what needs to be done next? How much time gets wasted because of this lack of clarity? And what can we do to reduce this waste? This waste is known as “process debt”.

If a person has one job, always does the same thing, and always passes on the work to the same next actor (person or department), such as working on a production line, then organizing their work is fairly straightforward, at least in the sense of always knowing what needs to be done now and next. But for most of us, this is not the case. We do many different things, working with many different people. Even if you are doing the same type of work, you may be receiving it from many people and passing on the results to many different people from different groups. It is far too easy for things to fall through the cracks – you don‘t notice an email asking you to do some work, you have to hunt to find out who to send work on to, you can’t track down all the material you need to do your job and don’t know who to ask, you forget a step,…

Given that most of our working lives are following processes, it is natural to ask if there is anything we can do to make that more efficient or effective. A quote from Abraham Lincoln is appropriate here: “If I had eight hours to chop down a tree, I’d spend the first six of them sharpening my axe.”. In other words, before just jumping in and starting a task, think about the task and how it can be made more effective. We can apply the same thinking at a higher level to processes and projects, not just individual tasks.

In practice in a process, what typically happens is that some person, as an actor in the process, carries out some action to create some output. Assuming the next action is carried out by some other person (though the same applies if the same actor continues), then the original actor has to:

• know what the next action is
• know what they need to supply for the next action to be carried out
• know who has to carry it out
• inform the next actor that there is work waiting for them and where they can find the necessary material

Ideally our systems make all these things easily visible.

So what’s the problem?

Our working lives would be much simpler if we didn’t have to spend so much time looking for the answers to the questions implied at the end of the previous section. In many organizations, far too much time is spent working around problems in the way we work within our processes where there is lack of clarity about the process and specific tasks within it. The two main issues are that we don’t have a clear definition of who needs to do what and when, and much information is not easily accessible.

In my consultancy career much of my work involved helping client organizations to define their processes and implement them in software tools. It was a very common experience to be in a workshop to understand a specific process and there would be disagreement among the client staff about how the process should work, even if it was notionally documented and they were all supposed to be following it. This highlights the need to define processes clearly and, perhaps just as important, make it easy for staff to follow them.

Is there a better way?

So what is the answer? Of course, there is no single solution, and people find lots of ways around it. For example, I have personally set up Outlook so that I can turn a message into a task in a couple of clicks, and have rules so that some messages automatically get turned into tasks. I have been in several meetings where people are doing amazing things with Excel spreadsheets to track work. But these are somewhat lacking. In the first case, the gains in productivity are limited to just one person – nobody else has access to my emails and l don‘t have access to theirs, although other people could, of course, use the same approach. In the second case, the spreadsheets are manually maintained and record status and, to a limited extent, next actions. In at least one case there were three different spreadsheets in use to manage essentially the same information for slightly different purposes so the potential for conflict and confusion was massive.

Some companies are fortunate in having knowledge bases of processes and materials. But these are often limited in a number of ways:

• They document processes but do not provide any support to ensure that they are followed.
• It is often difficult to find the appropriate material within them. Searching generally throws up a mass of material that matches whatever search term you have chosen but this often finds irrelevant material where the term occurs incidentally.
• There is generally no real structure and any tagging and categorization mechanisms are not used consistently.
• They are not always maintained consistently and hence become out of date.

What we really need is a tool to manage the work of a team, where people automatically get notified of their tasks, where status reporting and passing on work to the next step is as simple as checking a box and where the information needed to do a job is maintained consistently. Fortunately, there is a multitude of such workflow management tools available, ranging from the fairly simple to full-featured.

Process definition

The start point of all such tools is process definition. A process can essentially be defined by its inputs, its outputs, and the process itself - how it transforms the inputs to the outputs. This definition is itself recursive, as each process can be decomposed into other processes until you reach something atomic such as “add one to the count of widgets produced”. We also need to define who does the work. Each of these processes is the responsibility of some actor, which may be a person or, more likely, a job role or a team. In general, the overall process involves several actors.

Unfortunately, many of our processes are not well documented, if they are documented at all, so this first step can be quite difficult. You can almost guarantee that if more than one person is following a process they will actually be doing it in different ways. I have experienced this in customer meetings when I ask the customer engineers to explain their current process. Despite all believing they follow the same process, there are almost always people saying “that’s not how we do it”.

When you start to define a process, you will probably be surprised at how many distinct steps are involved. Some people’s reaction to this is that they cannot possibly define the process as there is no way that they can do that many things. The fact, of course, is that they do those things whether they are defined or not, and not defining them is the reason that essential steps get missed. So being honest is important. Some workflow tools only use a single level of definition, others allow you to define sub-processes. Defining sub-processes is useful for two reasons. First, it allows you to create a single definition for a common sub-process that is used in many places. Second, it allows you to defer the definition of detail, adding it when it becomes useful or necessary.

Having defined a process, you might decide to optimize it, using techniques such as Value-Stream Mapping. That is outside the scope of this post, but well worth looking into.

Using the tools

Workflow tools work in many different ways, the features generally provided include:

• Individuals can quickly identify their own work
• Individuals can quickly identify work products for which they are responsible
• Automatic notification of individuals when there is work waiting for them
• Ability to see upcoming work and its current state, including who is currently working on it

Additional features often found include:

• Ability to find the status of a work product
• Ability to identify unallocated tasks that are otherwise ready to be performed
• Dashboards providing management information on status, burndown, progress, etc.
• Prioritization of activities, generically and for specific instances
• Different views including, for example, Gantt charts, Kanban
• Time tracking. This is particularly useful when companies are still using timesheets, and hence the time spent, as a metric for work done, inaccurate, misleading and damaging though this is (perhaps a topic for another post)

Benefits

Most of the benefits have been discussed above, here is a quick summary:

• Individuals and teams know what they are supposed to be working on
• Individuals and teams know what work is upcoming, so can plan ahead
• Knowledge is available to all, not hidden in spreadsheets on personal computers
• Individuals and teams are notified when work is ready
• Managers and others can see the progress of tasks and the overall status of work

In short, work becomes much more efficient and effective.

A commenter on an earlier version of this post made the point that standardisation and digital processes can support lean, but it can also make processes rigid, less agile and can stifle creativity and continuous improvement. The need is to find the middle ground somewhere, where standardisation of key processes simplifies and reduces administrative burden, while leaving some things up to qualified, competent and experienced employees giving them the freedom to change things quickly should it be needed. You need a stable foundation to start from and the flexibility to tailor processes to a team’s or client’s needs.

Choosing the right tool

It would be ideal if there was a simple way to decide which tool to use. A useful reference is https://www,makeuseof.com/online-task-management-tips-choosing-right-app/. In the end, it comes down to which tool provides the best mix of features that you need for the price you can afford. In a small organization, almost any tool will provide benefits, at the risk that it may not allow for growth. A larger organization should probably consider running pilot projects with different tools.

Origin of tools

Workflow tools come from five main disciplines, project management, software development, business process management, document control, and task management. These disciplines overlap to a greater or lesser extent, so you find tools generally support more than one.

Project management tools, such as MS Project, arose from the need for large projects to be able to manage and report on their work and progress. They generally take a very hierarchical approach and so are suitable for work that is mostly planned in advance, such as most projects, but less so for more responsive tasks such as customer service, sales, etc.

Many tools originate in the need for software development teams to control change, which essentially restricts who can do what work on what content. This has led to the need to define the flow of work and then control it. There are some very simple, but still effective, tools in this area but they are not generally useful for the larger task of managing business processes.

More sophisticated tools, such as IBM’s Engineering Workflow Manager (formerly Rational Team Concert), have grown to include project planning, Kanban, workflow, issue management, and other facilities. These provide all that is needed in a workflow tool but can be difficult to configure and use and are best suited to organizations that can clearly define their processes and have the need to coordinate many people on many different activities.

Tools originating in business process management generally start from the foundation of drawing a business process as a flow diagram. Tools that start from this basis generally develop by allowing the definition of who can do each activity and what work products are involved. These are often the tools that are best suited to an organization that is starting to understand the need for some sophistication in how it manages its processes.

Tools originating in document control are similar to those originating in business process management, with more of an original emphasis on how documents can be changed and formally issued. These often have good electronic signature capabilities.

The tools coming from task management often start with the need to manage the tasks that an individual has to carry out. They gradually add sophistication, such as task dependencies and allocating work to different people. These are often suitable for organizations getting started in process management and can often grow to be sufficient even up to fairly complex situations.

Terms

Those of you in a technical field, especially software-related, will have heard the term “technical debt” being bandied about. According to Wikipedia: “Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.” (https://en.wikipedia.org/wiki/Technical_debt).

Reflecting this Wikipedia definition I have used the term “Process Debt”, which I define as: “Process debt reflects the implied cost of additional work caused by choosing an easy solution to a process problem now instead of using a better approach that would take longer”. To understand this, we need to take a step back. Let‘s start with the Wikipedia definition of a process: “A process is a series or set of activities that interact to produce a result: it may occur once-only or be recurrent or periodic.“ (https://en.wikipedia.org/wiki/Process). So pretty much everything we do is part of a process. What l am considering here are especially those processes that we repeat and form part of our business as usual, though much the same thinking can be applied to one-off processes.

Written with StackEdit.

The Power of Three

Planning top-down and bottom-up and three levels of abstraction

If you are like most people, you have things to do, or that you want to get done, that cover a range of timescales:

• You want to retire by a certain age
• You have a project with a deadline this year
• You need to decide what to have for dinner tonight

When people talk of planning horizons, this is what they mean. The usual advice is to plan from the longer timescales to the shorter. And that is, in general, good advice. But it's not always the right thing to do. There is another way of looking at this, and that is, if you will pardon the terminology, in terms of levels of abstraction. You will almost certainly be familiar with this concept, it recurs over and over again. Some examples:

Planning a military campaign:

• What is the Objective of the campaign?
• What Strategy and Tactics will you adopt to achieve the outcome?
• What Resources do you need to implement the Tactics?

For a project:

• What is the overall Outcome’?
• What Methods will you use to deliver the outcome?
• What Resources will you need to use those Methods’?

For organizational procedures:

• What Policies do you want to follow?
• What Processes will you adopt to meet the Policies?
• What Activities make up the Processes?

In a company:

• What is the Corporate goal?
• What is the Business approach?
• What has to happen at the Functional level?

Also in a company (looked at in another dimension):

• What is the Corporate goal?
• What is the Portfolio of products (or programme of projects)?
• What Products will you create (or projects will you work on)?

And most relevant to us, for a product or system:

• What do users need (stakeholder requirements)?
• What will the system do (system requirements)?
• What is the system (design and implementation)?

Generalizing, what we have in all these examples is:

• Purpose -- Why: A definition of the outcome that is desired: the purpose (which might be a problem to be solved) and the context within which it must be delivered
• Functions -- What: A definition of what must be done to deliver the outcome
• Artefacts -- How: The detail of what needs to be used and exactly how the outcome will be delivered

Sidenote
The use of the term "Purpose" is quite deliberate. in my experience, asking people "What is the purpose?“ of something they are proposing leads to deeper thought and more meaningful answers than asking seemingly similar questions like "What is it for?“, “What is the Goal?", etc.

Each of these levels of abstraction can include more or less detail, but that's a topic for another time.

A key point here is that describing things as more or less abstract doesn't mean that they are more or less real. Retiring at a certain age is no less real than saving a certain amount of money, which is no less real than setting up a specific type of investment.

So, what does all this mean in practice? For any goal you want to reach, there is a consistent set of steps that you should follow. This is:

• Define the purpose - the desired outcome (Why)
• Determine what must be done to deliver the outcome (What)
• Investigate possible means of doing those things (options for How)
• Decide on the best means (by whatever measure of "best" is appropriate) (How)
• Do it!

So going back to our planning horizon discussion at the top, this framework lets you put the planning horizons into context. Of course, there is far more to thinking about how to achieve a goal than that. Other topics I plan to cover in future blogs include:

• Problem and Solution domains - how does this relate to the three levels of abstraction?
• Are three layers enough? Surely we need to break them down further?
• How does modelling fit into this?
• What about iterative, incremental and agile working?
• I've heard about Design Thinking, how does this fit in’?

What is "Effectiveness"

In my introductory post, I said I would write on “effectiveness” but I didn’t say what this means. This post addresses that topic.

I am fascinated by the ways in which individuals and organizations can become more effective and my goal is to help you to do that. I have studied and used many approaches, from simple “To Do” lists to more complex systems such as Stephen Covey’s 7 Habits and David Allen’s Getting things Done and concluded that none of these provides a complete answer.

Introduction

Many years (decades) ago people who had to juggle lots of tasks and priorities concentrated on time management. Then came the realisation that this focused on the wrong thing. You were not managing time, you were managing how you used time. So the emphasis changed to managing what you do and when you do it. This was perhaps exemplified by David Allen’s Getting Things Done approach. Moving on from that, you now get people talking about productivity, to me, the leaders in this field are Francis Wade, Michael Hyatt and Mike Vardy, who come at it from different directions.

One thing that is common to all the current thought leaders and experts is a focus on improving what you get out of your time. Implicit in this, though rarely stated, is not just that you want to do (achieve) the most in the time available, but that you have created the most value (however you measure value) out of that time. This is why I prefer the term “effectiveness” over “productivity”. You can be tremendously productive but be producing the wrong things.

The OED defines effectiveness as the degree to which something is successful in producing a desired result.

Have you ever asked yourself how effective is your organisation, department or team in achieving the results you want? What about your systems and processes? Is everything running as well as it should – or is there room for improvement?

Making a difference

Focusing on improvement

Every organisation has an area that would benefit from producing better results. Imagine how different things would be if everyone and everything was performing exactly the way they should…

How effective is your organisation, department or team in achieving the results you want? Is everything running as well as it should – or is there room for improvement?

Effectiveness: Improving people, processes and systems

Effectiveness is successfully producing a desired result and consistently hitting goals. What does this mean to you and your business? You may manage time well, you may be efficient, you may be productive, each of these goes part way to achieving your goals, but are you as effective as you could be? You can become more effective: whether through better cost, time and quality management; report and presentation delivery; improved product and system development, or process management.

You become more effective by being more organized, more able to use your time well and, importantly, less stressed. And there are associated benefits:

• Work becomes easier, more enjoyable and less stressful.
• People know what is expected of them, when it is expected, and what is coming up in the future.
• Individual and collective performance and productivity increase.
• Accountability improves and company morale soars.

Achieving the outcomes you want

The first step to becoming more effective - and getting the outcomes you want – is recognising that there’s room for improvement. And there is always room for improvement.

What this involves

One of the key things I have learnt is that people focus on solutions before they have understood their problems. So first you need to work to understand what is stopping you from doing what you need to be effective.

Once you understand what is blocking you, you can start to work on what the solution might be and how you can go about implementing that solution.

There is no single approach that will provide the answer for everyone because there is no single question – everyone has different problems.

You become more effective by balancing cost, time and quality through using time effectively, writing and presenting well, improving product development and management and improving the effectiveness of your processes.

And how do I do that?

As you can imagine from the above, there are lots of areas that can be improved, and each of these has several approaches that can be considered. I intend to cover some of these in future posts. I do not intend to provide a comprehensive overview of all possible approaches in all areas, particularly where specialist knowledge of processes or industries are concerned. My background is mostly in systems engineering and software so that drives what I can write about to a large extent.

Written with StackEdit.

A new blog!

I used to blog rather infrequently at https://methods-and-music.blogspot.com but I last posted there over three years ago so rather than revive that I decided to start a new blog. So here it is.

I do intend to post rather more frequently than I used to. The topics will be mostly the same - that is, whatever I feel like writing (or ranting) about. These may, or may not, include:

• Systems engineering
• Music and musicians
• Things I have read
• Effectiveness

I'm going to try to not write about politics. It's frankly too depressing with the mess of Brexit and the most incompetent, malignant, criminal government in my lifetime.