If you do this, you will no doubt hear a tonne of ideas, concepts, visions & evolutions that could radically change how we perceive the world. To see proof of this, you only need to look back at the last ten years and see how radically our day to day world has changed. ​

http://uk.businessinsider.com/18-tech-products-that-didnt-exist-10-years-ago-2017-7/#1-the-ipad-1 ​

Nothing lasts forever and there`s always the next big thing. Has Agile won or is it dead already?
Angela Prentner Smith

Something I’ve been pondering for a while is what’s the next big thing in project delivery? Agile has been around for a while now, and businesses are still struggling with its adoption. I asked the IIBA (International Institute of Business Analysis) LinkedIn group what they thought, and I got about 40 differing opinions. I did some research and again I got a typical mix of views.
 
‘Agile is dead already.’
‘Agile was never meant to be used for what it is now.’
‘Agile is the only way.’
‘Businesses need to be agile, but that doesn’t mean they need to adopt a specific ‘agile methodology.’
 
The conclusion I’ve come to is that actually all of those opinions are right. Most importantly - there isn’t an ‘Agile’ silver bullet that you can implement into your business and make everything better. There isn’t a methodology that you can stringently adopt that will mean all your projects get delivered effortlessly. Indeed the very premise of agile, as a word, a concept and a manifesto, is about being adaptable and responding to change. A strict project or development methodology breaks that very premise. 
 
The Agile Manifesto
 
The Manifesto for Agile Software Development was just that. A manifesto for software development. The problem with that? It was never written to extend beyond software development. As those of us with war wounds from projects know - a large business project never starts and ends with just software development. Agile was developed to improve software development methodology. The original 17 founders of the agile manifesto, are still trying to do that. Some have moved on from the original manifesto and are looking at new and better ways of developing software. 
 
Death by Popularity
 
Yesterday I attended a conference on family friendly working. The word agile was used frequently to refer to flexible working in terms of hours and locations. I also heard agile used in reference to hotdesking. Whilst these applications of the word aren’t actually wrong - agile just means nimble and flexible - they do muddy the water when we have projects of work using Agile methodology. The popularity of the word agile and its potential overuse just adds to the confusion. 
 
There’s also the Agile Marketing movement, and more generally discussions on agile cultures.  Again both meritted uses of the word and potentially successful ethoses. However they may further add to the confusion when business leaders, technologists and marketeers come together to deliver a project - whose agile is this anyway?
 
Design vs Development
 
I’ve personally been stuck in the middle of this argument. What a design sprint entails in an agile world vs a front end development sprint don't deliver the same things, don’t have the same rates of execution, the same stakeholders and beyond. Sprint - that simple concept within the agile nomenclature can cause masses of confusion, and honestly they don’t really align. Design sprints need to test features with users quickly, and so does development, but front end to back end development don’t follow the same creative cycle of design and they have different gestation times.  Sprints are just time periods during which specific work has to be completed and made ready for review, but you can’t get the same amount of development done as design in the same timeframe.
 
Design methodologies
 
Service design, user and customer experience design, user interface design and all the rest could be described as methodologies themselves. But once the design has been done, and technology is required, the agile software development lifecycles begin. These should still iterate, test and learn with users, and business counterparts. They needn’t be at odds, but what is needed is clarity between the design methods and the project approach or development lifecycle. De-risking design and de-risking development can both be achieved through iteration - a key premise of agile, but not necessarily within the same sprint cycles.
 
Beyond Agile
 
I’ve read a bit on DevOps and think this might be where to hedge your bets on the future of software development at scale. Scaling is certainly one of the key criticisms of agile project methodology. What works to build a small app doesn’t necessarily scale to an enterprise wide programme. That said traditional waterfall methodology is flawed, as Mike Gill discussed in Seeing the Light and Go Agile or Go Home. 
 
Where that leaves us
 
So businesses need to be agile - that is flexible around the needs of their teams, their customers and logistically in line with the digital age. But that needn’t be confused with agile software methodology or design methodologies. The most important point in developing a project approach is:

1. That there is an approach that is communicated and understood by all participants
2. That it is not delivered in silos
3. That it is designed around the needs of the customer and that co-creation is looked for
4. There are common goals
5. It is open to change when things don’t work.

 
Meaning it matters less whether we call it agile or anything else and more that everyone knows what’s happening, is working together and willing to be progressive rather than dogmatic about the methodology.
 
I do believe agile is better than waterfall, but I don’t think that’s the last word on the subject.  There will be the next wave of software development methodology and beyond that businesses will be more agile as they are enable by technology and respond to the demands of the workforce and their customers.

We have launched an innovative, industry led solution to embedding people centred project disciplines into businesses to aid 'agile adoption' and 'digital transformation'.  We'd  love to share that with you.

What business leaders can gain  from our Horizon Watching service
​Denis Yordanov

 
​Information has always been important - not only for business, but to society as a whole. And information has always been around us, be it in the form of books, newspapers, or word of mouth. However, in recent decades, the amount of information available to us has increased exponentially and is increasing at even faster rates.

The way we access information has also changed. Through digital means, we have endless content at our fingertips. In fact, there’s so much information that it’s becoming increasingly hard to sift through it all and distill the most important pieces on which to base your decision-making. This is especially true for business leaders today - the rate of change has increased proportionally to the amount of information available.

It’s no longer sufficient for business leaders to gather information about what has happened to their business. In order to prosper, they need to know what is currently happening and more importantly what will happen in the future. They need to know what changes are taking place, what innovations there are, what their competitors are doing, and what the current and upcoming trends are. None of these exist in a vacuum and all of them act in constant reciprocity, it becomes almost impossible for individual business leaders to keep on top of all this. It's hard for them to justify spending their time and efforts  on forecasting what 'might happen' to their  business in the future opposed to what is happening to their business right now.  But the fact is that if you don't, you risk falling behind your competitors as you scramble to keep up. 

Horizon Watching - This is Milk's approach

This is Milk’s Horizon Watching service tackles this very issue.  It is exactly what it says on the tin: we aid you in discovering and assessing what’s potentially on the horizon for your business. We provide you  with information and predictions about trends, events, and changes that may take place in the future and help you examine what their impact will be on your business. We can compile a trend report for you with all the major trends that might shape your industry and we can work with you to analyse what they might mean for your business specifically. Finally, we can summarise and compile all findings and recommendations in one detailed report. This will help you to set strategy in the years to come and provide a roadmap to stay ahead of your competitors.

So how does it work?

• We look at various economic, technological, social, and environmental trends and the connections between them and analyse how they might impact your industry. Then we highlight the challenges and opportunities, all in one report.
• We host a one-day discovery day with you in which we look at the trends report and guide you and help you to think about what those trends might mean for your business specifically.
• Finally, we compile all findings and recommendations for the future and add them to the initial macro trends report.

Aim for the horizon and get in touch with us today!

The Milk Bar - Horizon Watching

The Milk Bar, our quarterly event where we discuss topics on transforming Scottish business for the better, is coming up soon! The topic of the next Milk Bar is on Horizon Watching and we have lined up some very relevant and engaging speakers and workshops.

When? Friday 5th August 2016, 17:30-19:30
Where? Snook Interchange Glasgow, 4th Floor, 84 Miller Street, Glasgow, G1 1DT

For more information on the speakers, the Milk Bar and to RSVP visit our Meet Up event page

Learn more about Horizon Watching and our other services!

Michael Gill, Agile Business Analyst, discusses the key tenets of the Agile Manifesto for software development and what they could mean for business.

 It's nearly fifteen years since seventeen IT professionals met at a ski resort in Utah, to explore an alternative to documentation driven, heavyweight software development processes. What emerged was the Agile Manifesto espousing four values and twelve principles. Here we look at what this might mean for an organisation either seeking to transition to or already embarked on an agile methodology.

Before I do that, however, let's think about what's happened since the Manifesto's launch, at least in technology terms. The internet was still in its infancy. Some technology experts and organisations weren't convinced of its longevity. Mobile phones were pretty much just that, a mobile phone, and desktop computing was dominated by Windows software. Not even the much vaunted 'Windows XP' had been released. And the terms 'social media' and 'Google' hadn't been invented. 

Since then there has been a revolution. More fundamental than perhaps the early years of the industrial revolution. The internet is part of the very fabric of all our lives. Smartphones, or more accurately, pocket computers are integral to the way we communicate and gather information. There are over 3.5 billion Google searches every day1, and to many the concept of a life without Facebook or Twitter is incomprehensible. New devices such as tablets or Kindles are part of our everyday fabric, and for many of us, Windows remains a distant memory as other players have established themselves in the market.

We live in a world where someone can wake up on a Monday morning with a great idea and weeks later millions of people across the world are running her software.

Yet despite this transformation, many organisations are stuck in the past as far as their development methodologies go. It's as if the last fifteen years never happened.

So what does the Agile Manifesto give us and what do the values actually mean? 

Here's the opening statement along with the four core values in their entirety:

"We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more."

Let's explore how this might play out by examining each of the values in turn.

1. Individuals and interactions over processes and tools

For many organisations, this value can be one of the most challenging. The emphasis on people and communication over rigidly sticking to a process is an uncomfortable place to be. 

By putting communications at the heart of everything you do, there is a greater likelihood of solutions being found to problems, issues aired and confronted, conflicts resolved and consequently forward momentum.

Where adherence to a process dominates, on the other hand, issues and conflicts are more likely to be hidden and glossed over. More emphasis is placed on conformity rather than achieving the end goal of building software. 'We all know our place' might be another way of putting it. 

Many financial institutions, for example, have a very hierarchical, even feudal management structure. This is one reason why these sorts of organisations struggle to adopt and benefit from agile. 

Emphasis is placed on the process, so we change from one form of box ticking in waterfall to another form in agile without ever truly understanding the philosophical shift necessary to realise that structure and hierarchy just aren't that relevant anymore.

The truly self-organising team can be a real challenge to the status quo. The idea that a group of individuals plan and innovate outside what is the norm can be seen as a threat. And many times the diktat will be 'you can be agile, but only so far.'

Adopting agile takes courage, honesty and a willingness to break with the past. The emphasis on people and communications is vital to making this a success.

2. Working software over comprehensive documentation

Hand in hand with an emphasis on the process is the production of documentation. After all, that's how we know the process is working, isn't it? 

What we need to concentrate on, however, is the reason we're developing in the first place - working software. 

I was working on a regulatory project some years back and we were legally obliged to deliver to a fixed deadline. Despite this, the project was starved of resources and instead the focus was on a bright shiny new system for another aspect of the business. Two years in, they were due to go live and informed the new incoming head of IT that there was a problem with the new system. 'Is it a problem in testing?' he naively asked, 'no,' came the reply 'we're still in analysis.' But at least there was lots of documentation.

Ask the question what does the documentation contribute to the goal of producing working software? Does it provide intrinsic value? Is anyone going to read it? If so, who and why?

Other factors to consider are the location of the team(s). Co-located teams with good communication will negate the need for reams of documents. Multiple teams in different locations and possibly time zones might require a degree of more formal documentation though this can still be done with a light touch.

As for the working software itself, this is production quality code, able to be released when it makes sense to do so. Make this the focus and eliminate unnecessary and costly documentation cottage industries. 

3. Customer collaboration over contract negotiation

You would think that collaboration as a concept would be a no-brainer, after all without it, pretty much most things involving two or more people won't have much chance of success. The central aspect of this value though is in the involvement of the business. 

Embedded, involved stakeholders are pivotal to the success of an agile project. Able to make quick decisions, constant involvement in re-planning, (re)prioritisation, guiding the team as they witness the growth of the (working) software week by week. Sometimes it's uncomfortable for them to be put on the spot, but rather a poor decision than no decision at all. 
Their involvement in ceremonies such as the 'stand up', and 'retrospective' fosters a greater degree of honesty. Helping to write or writing acceptance criteria, provides them with a real stake in the development and an investment in the project's success.

Of course collaboration extends to all the team members, some used to handing over documentation down the lines to other disciplines (contract negotiation), can struggle initially with regular interaction, but as they witness the organic growth of the system, they wonder how they ever did things differently. 

If you have to deal with third parties, then things can get a little trickier. Almost invariably you will be saddled with contract negotiation, and many companies make money on the number of change requests raised. 

If you can, you need to negotiate contracts where you can buy the third party's time for use as you see fit, harnessing them into your sprints for example or if they don't work in an agile manner letting them develop up front with incremental deliveries. This is a subject in its own right, but when negotiating with third parties ensure you have flexibility so you are not constrained by prehistoric working practices and philosophies. 

4. Responding to change over following a plan

Eisenhower once said, "In preparing for battle I have always found that plans are useless, but planning is indispensable." Who am I to argue with the great General? A detailed Gantt chart is a complete waste of time and money. 

I used to love creating long, complex project plans. Structuring detailed lists of tasks, assigning resources, creating weekly time-sheets, capturing actuals, it was like producing a work of art. It took a degree of courage for me to realise it had pretty much zero value. 

The reason? As soon as the plan was 'finished' it was out of date. Often, even before it had been distributed to the willing or unwilling participants. And keeping it up to date (yes I was one of the few statistically, who updated their plans) was a huge maintenance overhead. 

And of course, I've been on the receiving end of so many unrealistic plans. I remember one time when regardless of progress, the plan end date always remained the same. Any slippage was accounted for by shaving off time from subsequent 'not started' tasks, regardless of the effort necessary to complete them. Problems only surfaced when there was no time left to shave, we were reaching the end date but had lots more still to do. But up until then it was a success,  management was happy as things were 'going to plan'.

Unfortunately this is the problem. Plans become a method of appeasing layers of management, never reflect the reality on the ground and everyone's left scratching their heads when nothing's delivered.

So my advice, forget your Gantt charts, with the exception of a simple, easy to read milestone plan, that's about all they're fit for. 

Plans fail because of no control over scope and change. Traditionally waterfall has struggled with the very concept of change, after all, the requirements need to be locked down early so that everyone knows what they're building. Change has to be negotiated through a typically convoluted change management or change request process. And there is often fierce resistance to any change to the plan (the plan that doesn't reflect reality), as that will jeopardise the delivery. 

Agile, on the other hand, recognises that change is inevitable and accommodates it. It's part of the regular planning activity (note the word 'planning', not 'plan', Eisenhower would be proud). Change is put entirely in the hands of the business where it should be. Remove some piece of equivalently sized scope to accommodate the change, or accept a longer delivery time. Nothing new or revelatory here, but it leads to tight control over scope, and that control leads to working software within desired time frames.

What can Agile do for my business?

Keeping focussed on the left side of the values provides the opportunity to transform the way an organisation works and delivers software, leading to genuine change, and change for the better. 

And it hasn't stopped at software development. The Manifesto has evolved into a philosophy for business management in general, with executives latching on to agile practices such as its heavy emphasis on flexibility and collaboration. Which, when done properly, can be transformational for any organisation.

Similarly, other business disciplines are taking the spirit of agile and creating their own models and values, again derived from the original Manifesto, for example ‘agile marketing', 'agile UX' and so the list keeps growing...

You can find the full manifesto text, values and principles at agilemanifesto.org. I'll take a look at the twelve principles in a future post.

1 http://www.internetlivestats.com/google-search-statistics/

Michael Gill, Agile Business Analyst, on the origins of Waterfall methodology

There were rumours of course, that decades before, some fool called Copernicus had spouted the same nonsense on his death-bed, but nobody's taken him seriously. This Galileo, however, well he's a different story. To say that the Earth orbits round the Sun and is not the centre of the universe is clearly heresy. Fortunately the Church knows how to deal with him; place under permanent house arrest and force him to recant. 

And as for that so-called genius Sir Isaac Newton, who claims to have mathematically proved Galileo and Copernicus were right all along, what does he know?

Ever tried to climb up a Waterfall?

Let's transport ourselves forward in time, from the heady heights of astronomy into the heavenly world of software development. It's 2001 and the launch of the Agile manifesto. Living in more enlightened times, no one's threatening to burn this group of self-appointed industry experts or have them imprisoned. But it's right to be sceptical. After all why change what we've been doing for years? We have the Waterfall methodology.

You gather requirements, analyse, design, code, test, release. Alright, so quite often good communications are lacking. It doesn't facilitate change particularly well. It's hard to accurately plan and poor old test always seem to have their time squeezed, but after all it's only test. The finished product rarely matches the original business vision and delivery is frequently over budget and late. Better not tell the shareholders.

But should it have ever seen the light of day?

What if the adoption of Waterfall was built on shaky foundations? What if it's sequential model was never the intention?

With ever improving technology, software engineering as a new industry, had to find ways to manage the development of larger and larger systems.

As a contribution to the debate around this problem, in 1970 Dr. Winston Royce, now credited with Waterfall's introduction, issued the white paper 'Managing the development of large software systems'1

Dr. Royce lists each stage of the process:

• System requirements
• Software requirements
• Analysis
• Program Design
• Coding
• Testing
• Operations

We can all recognise this familiar model.

'I believe in this concept,' writes Dr. Royce, then immediately goes onto say 'but the implementation above is risky and invites failure.' He argues that by leaving the testing phase to the end, there is little or no opportunity for change should an error be discovered in a previous step. He concludes his premise by stating: 

'Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.'

To address this issue Dr. Royce proposes a series of elaborations iterating around the process, to capture errors and to avoid a calamity during the testing phase. The end result is a complex process diagram, which, when compared to the the basic waterfall model, so the story goes, led a Pentagon official to adopt the simple route instead of Dr. Royce's complex elaboration. And we've been living with the consequences ever since.

An earlier example of a fledgling Waterfall process in action appears in the reissued study 'Production of Large Computer Programs'2 by Herbert D. Benington, originally published in 1956. The paper describes the broadly successive steps undertaken to develop a large system and the per instruction costs around its production.

If it's broken, fix it

Reflecting in 1983 what he would have done differently, Benington concludes:

'I would have worked to test and evolve a system. I estimate that this evolving approach would have reduced our overall software development costs by 50 percent.'

Both Dr. Royce and Herbert Benington understood the flaws in the sequential model, not from any academic standpoint but from hard experience.
​
In 1992 Pope John Paul II officially recognised that Galileo had been right all along; 350 years after the event. It would be a pity to think that the software industry would take as long to recognise the broken software development methodology being used to this day, instead of promoting the practice of iteration and early testing as espoused by those heretics who launched the Agile manifesto in 2001.

1 http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
2 http://csse.usc.edu/TECHRPTS/1983/usccse83-501/usccse83-501.pdf

Angela Prentner-Smith

Change is constant, exhausting and happening quicker than ever. In business we are enabled by technology, challenged by competitors, pressured to deliver more by our customers, and expected to offer more to our people.  
​
It’s a pressure cooker - if we let it be.  

And sadly, what I’ve seen in our industry (and by this I broadly mean those we call business analysts, project managers, change consultants and so on) is an inability to meet these demands. Projects fail. They fail in meeting their objectives, often fail to deliver - or deliver meaning - and the people involved often have little faith in the project and leave with war wounds, demoralised and jaded.  To quote a business associate “I’ve never known a happy business analyst”. What a sad state of affairs. I could quote lots of research in the field of failed projects, but just do a quick google and it's all there. 

Then there’s the new world and small businesses, where I’m beginning to gain useful insights. There's sometimes little thought given to how best to approach a project or how to define what suppliers should do for them.

The desire and pressure to get things done quickly, often leaves re-work, as insight hasn’t been gathered or analysed and the change therefore, hasn’t been defined with a view of actual user needs. For example, I frequently hear – “I need a website”, or “I need SEO”.  Yes you do need these things, but they aren’t ‘it’. You need to look at who you’re talking to, what you are trying to achieve, what you are selling and how you are going to build and maintain it first. Your website and your SEO are just a part of the puzzle, and require a lot more than just visual and technical design.  
It's often just a lack of the skills required to effectively manage every element of a project, where key people are stretched beyond their skillsets - which is great for personal development, but sometimes we all need a bit of outside perspective and experience to define what a business needs. It is a skill, and it's what business analysts should be able to do. 

Or alternatively change just happens organically. To some extent this can’t be avoided. We can’t plan for every eventuality, we don’t have crystal balls, and we need to be flexible. But without foresight, design and management of your business’ change, you build in inefficiency, leave much to chance and often fail to measure how your business is doing.   

To quote Francis Bacon: 

So why aren’t businesses coming to business analysts and project managers for help with the change? I think there are two answers.

1. Our industry has an acknowledged competency issue.
2. There’s too much confusion about what we do. 

The term business analyst has become loaded, unclear and taken on way too much. People don’t know what we do, and if they do, they don’t think we’re generally good at it.

​This is quite an impassioned subject for me. I set up a whole business based on the belief that “Change, needs to change”.  I’m a passionate person. I want to deliver for the companies I work for.  I want to make things better, and I’m working out how to do this. I won’t get it right first time. I don’t think that’s possible. Change is an evolution. We learn as we go, it’s about capturing, and acting on this knowledge and empowering those around us to make decisions for the betterment of whatever it is we are doing. 

Here are my thoughts on why there is a poor perception of this industry. 
​
Change “management” is outmoded

The current industry for change professionals is huge, as we said – change is essential and certain. The people who have carved a career in project change are generally paid well, often on day rate contracts and have often stepped away  from permanent employment promising personal development, a hierarchical ladder to climb and empires to build. They are forming a buoyant contractor market that if played correctly they can float around in for a lifetime. However, projects themselves still have massive failure rates, lack satisfaction for the people working on them and generally are not progressive. 
​
Change is everything

It’s as broad a concept as you can get. Change management however is not. Change management could be defined as structures of people, with tools and methods of controlling change – generally speaking.  However, where I often see an issue is a clash between designing of change and delivery of change. It’s often a clash of cultures, for example, the architects seen as lofty, designers seen as whacky creatives, with no grip on the reality of delivery, and the delivery teams and change function seen as controlling and inflexible.  If not a creative clash, often it's the clash between "the Business" and "Technology".  I've always found this is a strange dualism - isn't everyone in a company "the Business"? 

Every team in your organisation should be working towards a common goal. That goal should be communicated, and embedded in your culture. Change management needs to embrace communication, innovation and creativity. The world is moving too quickly to stay with our current modes. 
 
Culture, customer and clarity are often absent in change frameworks

I have never - and I mean this - seen any focus on culture within  a single project I’ve worked on.  There are some good eggs out there that genuinely do focus on the customer and can produce clarity through their deliverables and their socialisation, but they are sadly not in the majority and rarely have the right project culture to support them. To my mind, the 3 key elements needed for a successful project are: 

• A culture of willingness - to learn, to work together, to be collaborative and to leave a legacy.
• Customer focus – at every stage, and for every project participant, the customer needs should be elicited, designed for, tested against and communicated. 
• Clarity – of roles and responsibilities, of approach, of deliverables, of success measures, drivers and objectives – and of the desired customer outcome.

There’s often vision and strategy and business objectives defined. Most usually by a person or group of people who are incentivised to build something that makes a profit, increases efficiency or just bring in a new system, but this somehow seems to get lost once a project is mobilised. Suddenly outcomes for the customer and the business are lost in jargon, change frameworks, project plans, politics and delivery pains. 


The industry has lost its competency

Demand has outstripped the ability of the market to deliver quality. 

Although there are many people in this industry with admirable skills, great personal resilience, subject matter expertise, experience and more – there are still fundamental competency issues in the profession. Even some of the most broadly accepted concepts within project delivery are not understood by those claiming the titles of business analyst, project manager or their ilk. For example- Agile – it’s not new, yet I still see masses of confusion over its definition, its implication and its application. I’ve heard several times “its Agile with a small a” – I’m sorry that’s just nonsense.  Agile is a methodology, a well-defined set of methods in fact – if you have to say its Agile with a small a – I doubt you understand what that means, and are attempting to excuse the point that you have a poorly defined project approach.

Defining and communicating a method for delivering your change is key to success, be that Agile or otherwise - these methodologies still have a place, when understood. 


We’ve made ‘change’ too hard to be good at. 

It’s as if we’ve tried to make business analysis (specifically), esoteric. We’ve come up with all these different languages for what we do, and you know what – they’re confusing.  If it’s really hard to understand the difference between business requirements and functional requirements – then I think the distinction has no place.  If it’s too hard for analysts to learn, how on earth can we expect our stakeholders, subject matter experts and delivery partners to understand what we are doing, why we are doing it and to fully respect our role? 

To my mind, our key role is communicating.  If the methods and the words we use to communicate aren’t understood by us or other project participants - we’ve failed.  


Change refuses to learn. 

There is an irony in our inability to genuinely learn from mistakes and build them into future projects and future change within a business. This inability isn’t a physical or systemic issue, it’s an unwillingness borne of culture based on blame, empire building and inflexibility. Often a lack of leadership and a loss of sight of the vision for the organisation, a lack of association with a community have led to individuals fighting for their own little piece of land, and defending what they are doing, pointing fingers and looking for blame. 

Instead shouldn’t we take a shared ownership approach to projects?  

What can we do about it? 

Despite the air of negativity here, I am a positive person. I believe in making things better, and I believe in our industry. But I genuinely feel it needs an overhaul, a progressive look at the new, and a new way of working. This is what I think we can do: 

• Develop new talent, with a focus on delivering for people and for customers. With a recognition of the skills and training required to effectively and dynamically deliver change for business. Mentor and lead this new talent to take pride in their work, be excited by the prospect of delivering for customers, listen to them and change Change as we go.
   
• Create clarity through avoidance of industry jargon, overly complex frameworks and get back to the nitty gritty.  If the people doing the jobs can’t understand what they are doing, how on earth can their customers, or the suppliers?  Define approaches, scopes and deliverables in ways people understand and in reflection of the goals that the change, the organisation and the people involved, are aiming to achieve. 
  
  
• Create projects and businesses that people want to work for. Inspire them through leadership, mentoring, career and personal development. Be cognisant of what people want from the workplace. I doubt very much if it's land grabs, hierarchy and power struggle.  Involve people in the definition of the workplace culture, allow them flexibility to grow personally, and have lives outside work.
  
  
• Embrace change in change – if something isn’t working - try something new.  Change is an evolution. It’s as broad a concept as they come, and a one-size-fits-all methodology just isn’t working. So let’s change, and build change into change. Let's stop being afraid of learning from mistakes. Every project has its own personality – it’s own DNA, dictated by the company culture, and the make up of the people involved, so why do we think a stringent change methodology will work every time? It won’t.
  ​

Well that’s what I think right now, but as I keep learning and gain more experience, I’ll embrace that and change my views.  I’ll change, and my business will change – and that’s good. Good for change, and good for businesses. 

Find out how we can help you deal with change!

Angela Prentner-Smith

A pretty bold statement, coming from a business analyst, right?  But, I believe this 100%. I better back up my statement then.  Let’s look at how we can improve the perception of business requirements.

What is the problem with business requirements?

I have heard countless times, and probably even said myself, things like:

“These requirements are crap.”

“That isn’t even a requirement.”

“If you put sh*t in, you get sh*t out.”

This needs to be addressed. Why are they so open to criticism?

Let’s take a quick look at what I mean by requirements.  I’m talking about business requirements - in a broad sense covering user stories, high level requirements, use cases and anything else used to define a business need.  That’s all a requirement is – the capture of a business need.  My statement is equally true however of system requirements – the capture of what a system needs to do.

My background is working on large programmes and projects of change – and it’s with this background I make my assertion.  However, I believe the same statement is true of any change.  My belief is that, even if your business isn’t “engineering requirements”, you still have business needs, and are most likely eliciting and capturing them in some way.  Within small companies, you probably deal with changes in these needs quite pragmatically.  The issue comes about when change methodology, corporate culture and stringent gateways, with a lack of a fluid change control method turn the business requirements into a gospel.  A gospel to be tarnished with blame, dispute and to become a fighting ground for stakeholders and delivery teams.

Now, I’m not saying that requirements aren’t necessary – I believe quite the opposite.  Any business should and would benefit from understanding their needs before embarking upon change.  Indeed, how else would we tell suppliers what we need them to do, how else would we estimate scale and cost, how else would we assess impacts?  Business needs should be captured and managed, enough said.

So when I say they will always be wrong, let’s look at how we get to business requirements.  Business requirements, user stories, or however else you are documenting your needs, generally come after the vision, strategy, scope etc. of a project.  Stakeholders are pulled together, or a product owner is defined, and whether you are using agile or waterfall methodology, or something else you’ve come up with, requirements are elicited by the business analyst. 

Why are they always wrong?

There are 3 things with this process that lead to requirements always being wrong:

1.       They are written at a point in time.  They were gathered based on the knowledge of those involved at the time.  Everything moves on.  So why on earth would you expect a document of needs captured at one point in time to be the truth? As projects progress, knowledge gathers, needs change.

2.       They are only as good as their input.  You have a room of stakeholders and subject matter experts, and sponsors and delivery partners, all with diverse backgrounds and differing viewpoints.  They all have their view of the world, and are unlikely to all be on the same page, of the same level of knowledge, and in complete agreement.  Therefore your requirements are only as good as the input they give you, which will be variable in quality.  Additionally your requirements are a compromise from the very start.

3.       They are produced by humans.  The one thing all of your requirements have in common – they were produced by a human.  Therefore open to human error.  End of story.  They’ll be wrong.  You can’t possibly expect every line of what can be hundreds of business requirements not to contain any errors.

So what do we do about it?

Stop – and I mean everybody - stop doing these things:

Expecting the requirements to do everything
Requirements are just one project artefact.  They document business need.  Do not expect them to define the design, the test strategy or anything else.

Expecting the requirements to be immutable
They were captured at a point in time – of course they are going to change, as knowledge develops and change matures.

Expecting the requirements to contain solution
They should never.  I repeat, requirements should never contain solution.  And by solution, I don’t just mean technical.  They should not contain the wording of a question, the heading of a web page etc, etc.  There’s a good reason for this!  If you put solution into your requirements, you do 3 things that you want to avoid.

1. You constrain your design.  I’ll give an example.  You know a question in an online app is difficult to understand and needs to change.  So you write the new wording into a requirement i.e. the solution.  Seems simple enough?  No harm right? Wrong!  What if the new wording is wrong, and through some customer engagement you validate that yes, the question needs to change, but your wording was wrong and customers don’t understand it?  You’ve constrained yourself with no need.  Suddenly you have a requirement being pushed through build and test, but it’s wrong – so you need to change it – which can create a new change process.  Just don’t constrain yourself in the first place.  
2.  You muddy what requirements do.  Requirements are business needs, if you start putting some solution in, you set the expectation that the solution or anything else will be contained within the business requirements.  All those other things you need, are someone else’s job, or are a different document.  Keep them clean people, and please stop doing everyone else’s jobs!  
3. You stop focussing on the real need.  When you stop focussing on the need, and start to look elsewhere, you aren’t doing the job right.  You stop questioning properly, and this is bad.  So when a stakeholder says to you we need System X to do ABC – that isn’t a business requirement.  You need to ask why they need that, and what benefit that would bring.  Then you will get the real business need.  That may be that they need a process to be completed quicker, or a method of recording an element of data.

Methodology:  Define what needs to be done and who is doing it.

First of all – define your project roles and responsibilities, and the associated deliverables.  You let everyone know what their job is, what their role in the production of deliverables is, and what the purpose of the deliverable is.  Make sure you communicate this clearly, and get everyone’s buy in.

This will:

1. Create clarity of the purpose of deliverables, therefore avoiding the problem of the requirements being expected to define anything other than a business need.
2.  Ensure stakeholders and recipients of the requirements are engaged and understand their role in the production of the requirements and the project.  Create a sense of shared ownership.
3. Clarify the role of the business analyst – and stop them doing everyone else’s job.

Create a method to change the requirements.

The next step is to create and communicate a method to change the requirements.  Regardless of your overall methodology, you need a change control mechanism to track and communicate changes to requirements.  The best change control processes are nimble and quick, but still provide traceability.  I won’t go into this too much here – I think that’s maybe another article.  Like everything else, make sure everyone knows the process and has bought into it.

Foster a good project culture

Part of the issue in projects where statements like those I first quoted – is culture.  A culture with a lack of empowerment and decision making, and one where people are not working towards the same objectives, only produces blame and finger pointing.  A culture where everyone is working towards a common goal, feels shared ownership of success and failure and is empowered to make things better, make decisions and move on will help your requirements do a better job.  Not because your requirements are better but because the people using them are all on the same page.

Learn and improve

And back to my initial point - stop expecting the requirements to be right in the first place.  They can’t possibly be.  So stop blaming the requirements for your project’s foibles.  Yes, there are bad requirements out there – but you know what – there’s bad everything.  Expect some duffs in there, and move on.  Don’t waste time and effort with criticism, and if there are genuinely things that can be done better, debrief, record your lessons learned and build the learnings into your future projects!

Find out how we can help your business learn and improve!