My Red Flags

Over the course of 23 years as an ABAP developer, mostly as a contractor or in consulting, I have developed some “spidey senses” about when or how things will go wrong. I still run into trouble, and it is always when I have ignored these warning signs. These have become red flags that pop up and when I pay attention to them, and take action, I can often head issues off at the pass.

This discussion covers my experience over many consulting, contract and permanent employment and it not really related to a specific customer I have worked for.

I wish I could raise the issues covered here to the managers of the projects I was on and even at senior management level but mostly I see an unwillingness from those at higher levels to hear about these issues. They could save themselves a lot of stress around projects if they just spoke to the developers every other day. This seems to be some kind of subversive suggestion and wildly unlikely to be taken seriously, and it is disappointing that we live in a world where it seems that less communication is a preferred strategy. Another obstacle to this is that developers generally don’t like to be bothered or feel hounded when they are busy.

More communication is a serious suggestion - if project managers and other senior managers spoke to the developers in their team every second day and asked them: “How are you doing” and “what is slowing you down?” (in different ways) they would be sitting on a goldmine of information to improve their chances of success. I want to be clear here – this would need to be actual one-on-one conversations with an individual, preferably in-person as opposed to online. NOT in a scrum meeting. There is also an assumption here that the person asking the questions can establish a rapport with those they are talking to.

Here are some of the issues I have encountered so many times that I can confidently say that they cause real world problems for successful project delivery.

Requirements Gathering AND Solution Design together

Often there is no real difference between the requirements gathering phase and the solution design phase. I have seen people designing the solution while they are gathering the requirements either for a single piece of work or at project level. This gets really messy when you need to change the solution. When everything is mashed together it is hard to change the approach. If you have a very distinct user requirement and a very distinct solution design, you can flush your first solution design down the toilet with little consequence. Moving to a new design is much easier. Handling these two steps separately gives you a lot of flexibility to change your approach without being heavily penalised for doing so.

Human Centred Design and SAP AppHaus are both methodologies that separate out the requirements and design phases and are great tools to go through the process from start to finish.

Functional Consultants that design the technical solution.

This is just a “no-no”. This has become an even more serious problem over the last 5 years as the methodologies of ABAP development have changed. We now have “code pushdown” that pushes a lot of the business logic down to database level. We have low-code/no-code solutions, RAP development (RESTful Application Programming methodology), CAP development (Cloud Application Programming methodology), ABAP in the cloud, etc. The options for a specific solution are varied. There are also many functional consultants in the industry that “used to write some code”.

As a result, I still get specs with the functional consultant telling me how to loop through the data and transform it in various ways. This means I now have to reverse engineer the spec to figure out what is wanted and then implement that using the newer techniques we have available to us. This is a waste, let technical people do the technical solution design. Proposing enhancements or giving details of the source tables and fields or standard functions that are available is of course useful, especially for a new developer in that specific area.

?

When I can't communicate to users for simple questions or to clarify the business requirement

I have bumped into this in a variety of scenarios and projects. This is not good, blocking a developer from getting the information they need is guaranteeing that they will at best produce a subpar solution and at worst produce something unusable by the recipients. Developers should have open access to the users, the functional consultants and anyone else they need to talk to to help them move forward. Even when I have mentioned this to managers and the response has been: “On no, you should be able to talk to whoever you need to.” And then they have not taken any meaningful action, resulting in me still not being able to talk to the right people. Often the blocking action is quite underhanded and problematic. I know the natural response from anyone reading this is: “Are you serious? Surely you just go speak to the person you need to speak to?” This is not as simple as it seems. I have worked in environments where doing that has negative consequences. This problem is insidious and often implemented in an under-handed way that managers in the area are unaware of.

?

Someone hoarding information or access to others

This is a form of corporate sabotage that I have seen here and there. I once worked with someone (names changed to protect the guilty parties) that onboarded me onto the project. Jimmy told me: “I speak to Janice (Program Manager) every day and update her on everything that’s going on. So, talk to me when you need anything.”

I spoke to Jimmy every day and the work I was busy with had a revolving door of changing requirements (discussed later as another red flag). I kept speaking to Jimmy every day where I would often get a change in the requirement from him, as communicated from Janice. I would then give him an estimate of the amount of time this would add to the delivery. With near daily change, the amount of time being added started becoming significant. I also noticed that the delivery date was not changing.

Eventually, when the due date was looming and I couldn’t understand why it wasn’t changing, I said to Jimmy: “Are you updating Janice on the delays and the new dates? This piece of work just cannot be delivered by that date.”

Jimmy said: “No. If you need to tell her about the delays you better do that.” I was gobsmacked. This was months into the project, and she was not getting the feedback I was giving every day.

In that case I was lucky. There were numerous issues on that project and the week before I had compiled all the issues and all the delays into an email and sent it to my boss and my boss’s boss. This was more by chance than any real fortune telling on my part. When it exploded a few days later they knew exactly what was going on and were able to handle the problems that came up. But I know if I had not done that, I would have had some serious problems with my future in that company.

While my reputation internally was not wrecked the program manager told me that she was unhappy that I did not communicate the delays to her and I was moved off the project shortly after for "other" reasons. Guess who stayed on?

Someone who is “indispensable”

This is similar to the previous point, but this is more subtle and is also like someone who sets themselves up as the relay point for all information. Like a central point for everything. This can be extremely problematic. Not only are they a bottleneck but people who do this often have serious control issues and their control over the project is much more a strangling effect than anything else.

Additionally, if you have someone in your business that is “indispensable” or “irreplaceable” you have introduced some serious risk into your business. Interestingly, in my experience, these are often people that leave really suddenly.

Over Complicating the Solution

Many of the issues discussed here happen in the business or planning space. Issues that are caused by or made worse by project managers, application managers, BAs, etc. This problem is generally an issue caused by a developer. Beware the developer that brings you highly impressive, complicated solutions. What most other IT members and project members don’t seem to know is that when a developer implements a new solution, he is nearly always working with something new to him or her. Either the business domain, or a new way of implementing the code or something like that. In SAP, a developer that has experience in the “Sales and Distribution” space can quite easily implement a solution in the “Materials Management” space. They already know the programming language, the development platform and tools and most of the data-model. All they need is to find the relevant tables they might not know and a few SAP-specific functions they can use. When you work in a new space implementing a solution often follows this path:

1.????? Solution study

2.????? A first draft complicated solution

3.????? Refinement and simplification (can be multiple time)

One issue is that some developers skip point 3 above.

More seriously, some developers will strive for the most complicated solution. This will be their goal. They don’t care if other developers will struggle to maintain the overly complicated monstrosity that they have created. They don’t care about the additional maintenance cost they are placing on their customer. It is a badge of pride to prove how smart they are. They are very proud of the fact that they have been able to create something that others will have real difficulty in understanding and modifying. This is a serious, often unrecognized problem and it occurs WAY more often than business users expect.

When observing developers that fall into this category, their communication with the business is heavily loaded with technical terms and other obfuscating symbols, diagrams and language. The business users kind of give up trying to understand the solution on the basis that if the person can produce explanations that are so complicated then they must know what they’re doing.

They do know what they’re doing – they’re overcomplicating the hell out of the solution.

If you can identify developers that overcomplicate solutions and remove them from your project you will have a much bigger chance of success on that project.

Ever changing requirements

This is a biggie and probably the single biggest reason for project failure in my opinion.

I remember, years ago, walking into a project on day 1 of development. The plan was to sit down, go through the requirements, get briefed by the functional team, go through the solution design and then start coding. As I started to go through the documentation it slowly dawned on me that the requirements gathering, and solution design were incomplete and that I could not start development.

The MD walked past my desk. He was directly involved with the delivery of the project. I stopped him and told him: “Sorry but these documents are incomplete, we can’t start development until they are ready. I literally don’t know what they want.”

The guy looked like he was about to have some kind of mental meltdown. His response was: “Just start writing code. When we know what they want we can change it to match the requirement.” You heard me right. I was speechless and spent weeks pretending to write code. It is astonishing how often the needs of a technology partner conflict with the successful delivery of the project. Bringing on the developers too early is one example of this. It was clear that the project was not ready to start the development phase, but the developers were sitting on the bench. Clearly a much better solution is to get them billing and then figure out what to deliver.

But the single biggest red flag for changing requirements is this: it means the end-users, or the customer:

1.????? Don’t know their current process.

2.????? Don’t know how they want their new process to work.

This is a huge risk to the project.

Additionally, everyone seems to believe that when a technology partner and a customer sign an agreement to deliver a project that that is the agreement, this is not fully correct. The legal contract is an agreement that they will deliver, the requirement is what they will deliver.

Changing requirements are a ginormous red flag for project success. I am just amazed that there is no tracker for changing requirements that reflects directly onto the risk of project success. I see all kinds of risk management on projects but the biggest risk of them all are ever changing requirements, yet this is nearly always absent from any form of risk management. There should be a list of all requirements changes as well as impact assessments for each.

?

Scope Creep and Scope Changes

Scope creep is when a deliverable is added to the project, or an existing deliverable expands from an original smaller piece of work. Scope change is when the way a deliverable will be developed is changed or the requirement is substituted with a different requirement as if they are interchangeable. The biggest problem with both scope creep and scope changes is that these are often implemented within a project under the radar and without approval. This is like death by a thousand cuts. Both impact the timeline and the delivery deadline of the project, at the same time most of the senior people can’t understand why everything is taking so long. They’re not talking to their developers every second day, so they don’t know that they are encountering scope creep, changes in scope and various changing requirements. I asked most developers would be willing to raise issues of scope creep and changing requirements, but I have seen plenty of project managers and people above them unwilling to listen.

Project managers and more senior managers will often accept this change “just this once” but they do this nearly every day and somehow can’t see the cumulative effect of their decisions. It’s very much like the proverbial frog in the pot of water, warming slowly.

Are developers free of any responsibility in this area? No. I have seen a fair number of developers that will accept scope creep and changes in requirements with nary a peep. This is not great, but it often happens in a climate where pushing back is clearly not welcome.

I’ve been on a project where every time it became clear that the delivery date was under pressure the project management team would sit down and “re-plan” everything. “Move this forward, move this back, etc.” and juggle everything around without doing a single thing to find out what was causing the delivery to fall behind. They then fully expected that shuffling everything around like a deck of cards had resolved the delivery issues and were surprised every time to find that they did not in fact solve the problem.

I was once on a project where it became clear that the deadline was not going to be met. The project management team completely replanned the delivery of the entire project over the weekend. They did not involve a single technical person in the re-planning process, not even the technical delivery manager (me), the person responsible for actually delivering the work with his team of developers. When I checked their “replanning” I found that they had allocated nearly three times the number of hours to be delivered compared to what was available from the development team by the deadline. It’s telling that when I discovered this, I wasn’t even surprised.

?

Being told that "the details are still being finalised"

This is a killer to your delivery. There are a multitude of reasons why the details are not final, but this issue causes major problems. If the details are not finalised, DON’T start development. Most non-programmers don’t understand why the details are so important but in programming the details are everything.

Imagine putting the empty chassis of a vehicle on a production line and pressing “start” when there are 12 points on the production line which are not yet finalised. The engine “boring” machine doesn’t know the diameter of the piston holes, the wheel size has not yet been finalised, the interface for the electrical system between the dashboard and the engine is not yet defined, and there are many more undefined issues. What do you think the chances are of that vehicle being driven off the production line at the end?

Agile has undermined the concept of upfront requirements gathering with a “just in time” requirements gathering approach. No one has really noticed that Agile evolved mainly for web development where changes are generally single functions being added to a web page or an app. In this scenario extensive requirements gathering, and documentation can be a real drag on your productivity. Having said that, this approach is not suitable for enterprise grade ERP software upgrades and large projects. Starting an SAP project when you don’t know what you’re going to deliver is like jumping out of a plane without a parachute. I admire your bravery, but I don’t think your chances are very good. I actually like Agile, for the most part it does well as a project methodology, but I see too many businesses using it as an excuse to avoid requirements gathering and basic important documentation. And then when someone questions the process they are told: “Well we’re not fully Agile.” As if this fixes the problem.

Other variants of this problem are:

“We will be doing this piece of work in phases” or “in iterations”

Enough is known for the developer to start work but more will come to light later. This can cause serious problems with your delivery especially when, as is often the case, the newer part of the work requires the developer to make major changes to what they have already done. This is not a theoretical exercise but has happened nearly every time I have heard: “We will be doing this piece of work in phases” or “in iterations”.

No quality gate for specs

This is seriously problematic. I have lost count of the amount of time I been given a piece of work only to find the spec, assumed to be awesome, has serious deficiencies. The problem is then compounded when the developer has to go and do requirements gathering when he should be delivering. If you’re a project manager or in charge of delivery – do you know how often this happens? If the answer is “no”, then you aren’t speaking to your developers (in person, face-to-face) every second day, are you?

Most developers don’t even raise these issues anymore. They just work around them in various ways, but the lost time is significant.

No dev "acceptance" step

This goes along with the previous point. Once the spec has been reviewed by a technical specialist it should be either accepted or rejected in the workflow. If rejected, details must be provided of what needs to be done for the spec to get through the quality gate. If instead the spec is accepted, the developer can start work.

When implemented well these two steps contribute to the successful outcome of a project.

?

When asking for detailed information being offered: "Can we just get on a call?"

The short answer is “No”. The reason is simple, the likelihood of me achieving enlightenment from a phone call if the spec is incomplete or deficient in some way tends toward 0. There are some people who are experts at hand-waving and generalising, and they sound like they have said meaningful things packed with detailed information when they have in fact done no such thing.

I have had too many experiences of getting off a call with someone ready to start the work and as I tried to get going, I have been hit with the slow realization that I in fact have no idea what they want. And it isn’t in the spec and now they spent an hour “explaining” it to me and I still don’t get it. There must be something wrong with me, right? I am obviously not smart enough to understand what they so clearly spelled out.

My super-annoying answer these days is my favourite: “No thanks. Just put it in the spec then when I need it it will be right there for me to work from when I get there.”

I have found that as an act of self-preservation there are certain things I insist on being done in a certain way. I have never seen “getting on a call” resulting in a better outcome. There are exceptions. If the spec is done and the functional consultant wants to demo some aspects of the existing system or educate the developer in the process that can definitely be useful. Information from users, discussions and pain-points and various other meetings can be useful and productive. But if I say: “in section 2 where you detailed the PO process, I will need to know how you expect “a” and “b” to be done.” In this case, getting on a call does not help. Putting it in the spec helps A LOT.

?

“When will it be ready?”

Being continuously asked how long something will take when the above issues are in play – specifically changing requirements and missing details is seriously problematic.

I feel like if I could choose a superpower, I might choose the power of having someone say out loud, what they ACTUALLY mean with their question. For example: when asked in a meeting “When can this piece of work be completed?" they would have to say: “The requirement is half-baked and embarrassing to be honest. We’ve set you up to fail to hide our failures in requirements gathering. Please give us a date we can hold against you for our future scape-goating strategy.”

When you see developers react kind of aggressively to being asked when their work will be ready it is not because they are ornery. It is because they have been victims of date scape-goating in the past.

As a developer this experience is kind of fascinating. When I have given the reasons why I cannot give a date, the strategy becomes trying to fool me into giving a date with many many reasons why I can give a date, any date for goodness’ sake!

Scrum Master: “Okay, assume you get the full requirement by Friday, when it will be ready?”

Me: “I need the requirement to estimate how much work it is.”

Scrum Master (now crying): “Please just give me anything to work with.”

Me: “No.”

?

Severe Incompetence

This is a subject which makes people extremely uncomfortable. Most people I have dealt with are not comfortable calling out someone who cannot do their job. This is unfortunate because there is a real and significant cost to the amount of time wasted in projects by people who are incompetent. This is of course not every project, but I have been on enough projects with one or more incompetent people that I can see the very real ramifications this has on the success, or more likely, failure of the project.

I can remember the times when I have had a slow dawning realisation that the person I am relying on to deliver an important piece of work doesn’t know their arse from their elbow. This should be addressed but I don’t see anyone doing anything about it in the near future. It seems to be one of those “unconfrontable” issues.

What is interesting to me is that the people I have encountered in this category are very much aware that they are incompetent. As a result, they spend a significant amount of their time hand-waving and generating smoke screens and using metaphorical mirrors to deflect difficult questions. People they work with can also sense how stressed they are, but they assume the stress is due to their workload. And yes, these people are often overloaded, but it is because they can’t finish anything, and they make sure everyone knows how overloaded they are.

I have worked with someone that did everything in their power to avoid writing down answers to the many questions I had with most responses to my questions being: “Could we just get on a call?” (See the earlier section by that name.)

With my super-annoying riposte being: “No thanks, if you could just put it in the spec that would be great. Then I don’t have to ask again when I get to it later. I can just reference the document.”

This same person got very unhappy with me when I started using the “New Comment” facility in Word to ask questions in the spec, a shared document. It took me a while to realise that they were very aware that this was a recorded display of their inability to gather very basic requirements from the user. They insisted that I communicate with them directly in Teams as this was waaay more convenient, it was also (of course) more private where no one else could see me asking the most basic questions.

A report that I worked on for the individual concerned, which with a completed spec would have been about 3-5 weeks of work took me 7 months to complete, and it was not what the users wanted.

One of the problems is that there a numerous people on a project that actually don’t determine the speed and success of the project through their direct work. Project Managers are a good example. They are not part of the technical delivery of the project, yet they are made responsible for the successful delivery of the project. This is really problematic because they then have to invent various ways of trying to impact the success of the project and this could go, mainly, in one of two directions:

1.????? The PM has a positive impact on the project by:

a.????? Speaking to the developers to find out what barriers they are encountering and working to eliminate those barriers.

b.????? Ensuring that the requirements gathering process is done thoroughly and highlighting where there are shortcomings to improve the level of accuracy and detail in the documents being produced and the sessions being held.

c.????? Ensuring that the specs that are delivered are of a high quality and implementing quality gates for requirements gathering and spec production.

d.????? Implementing reviews of the requirements and solutions and the specs by knowledgeable people.

e.????? And whatever else needs to be done.

2.????? The PM has a negative impact on the project by:

a.????? Thinking that having more meetings makes people more productive (this is not tongue in cheek, I have direct experience with PMs who were convinced that adding more and more meetings with the technical delivery team would improve the chances of success of the project.)

b.????? Thinking that by assessing and modifying the work tickets for the project improve chances of success. Like filling in deadline dates for a piece of work then they have no idea of the quality of the spec.

?

They All Play Together

A lot of the issues discussed above play together in a project, intensifying the pressure and making it hard to spot the cause of all the turbulence being encountered. Even if you can’t nail the exact reasons why the project is struggling there are steps that can be taken to improve your chances of success significantly.

1.????? Get someone in the business, a process expert or business analyst, to read all the specs and review them for quality, accuracy and other important metrics. Give feedback to the author and list any deficiencies that need to be fixed. (It would not be that hard to develop some basic metrics for a spec to ascertain the quality.)

2.????? Once ready have a technical lead read the spec and either accept it or reject it. If rejected a list of issues that need to be fixed must be provided.

3.????? If accepted let the developer start work.

4.????? Senior people need to speak to the developers regularly 2-3 times a week. In person, face-to-face. They also need to be open to having uncomfortable conversations about what might not be working and also who might not be able to produce what is needed.

It doesn’t matter if you’re Agile or Waterfall or what “ology” you’re practising, ignoring these fundamental issues is a serious risk to your project.

I know this sounds very much like “this one time, at band camp” but after 20 years seeing the same mistakes being made gives me kind of a sinking feeling. None of the issues I have brought up here are new. They’ve been with us from the delivery of the very first IT project.

Taking mitigating actions will lay the foundation for a successful outcome on your project.