We are an IT Solution provider and I work as a Business Analyst. We are in the phase of streamlining our processes and procedures for software development projects. One of our core activity is to participate as a software bidder for various tenders.In addition we also encounter change requirements coming up from existing and new clients.

Our organization is projectised. We have Team Leads(TLs) reporting to Development Manager(DM), whereas I as BA report to Project Manager(PM).

Recently, we designed Standard Operational Procedures (SOPs) for the following:

  1. SOP WWorkflow for New Project before being awarded
  2. SOP Workflow for New Project after being awarded
  3. SOP Workflow for Change Request/New Enhancement

Here are our flowcharts:

enter image description here

enter image description here

enter image description here

We are seeking expert advice on the aforementioned processes and agile methodologies. Please justify your answers with sound and professional reasons based on proven experience for software projects in the real world.

2 Answers 2


TL;DR: Those SOPs are not Agile at all and suffer from all the shortcomings of traditional Waterfall projects. In Agile methods:

  • Requirements are never frozen. Changing a requirement that isn't realized yet is cheap.
  • Development & QA are close together, without any quality gates
  • Projects are executed in short iterations, with feedback from the client(-representative) at the end of each iteration. This feedback can change what gets implemented next and the Scope of Work.

Those flowcharts describe a fairly typical Waterfall process, with all requirements being set in stone before the first line of code is written and the customer only seeing the final product.
The process does not seem to have any agility in it.

The process can work well if your client knows exactly what they want, but the only clients where I have seen that kind of up-front knowledge is if the client itself is developing its own products and has been doing that for a while.

If the client doesn't have the expertise to ask for a quote based on a full requirements specification written by them, then you need way more interaction with the client during development to get timely feedback on

  • whether your understanding of the requirements still matches with the understanding of the client.
  • how the partial solution they have seen has affected their vision for the final product.

All Agile methodologies are all built around being able to react quickly to changes in reality, including the reality that clients repeatedly change their mind halfway through. This is mostly realized by not setting anything in stone except the work that is currently being done. Especially the work that has not been started yet can be changed at a moments notice and without (big) consequences.

Another characteristic of Agile methods is that development and QA are tightly integrated, often to the point that testers and developers are in the same team. There is also no quality-gate between implementation and QA.
Some Agile processes have quality gates at the beginning of an iteration (Definition of Ready) and for when the work is completed (Definition of Done).

In a project-based organization, it is best to apply a iteration-based Agile process (like Scrum), because then you can have a Stop/Continue decision at the end of each iteration. Processes that are based continuous flow (like Kanban) don't have a natural point to do those decisions.

It is easiest to see how to apply Agile methods in a time/material project, because the client essentially buys a single iteration of work at a time. And with a typical iteration length of under 4 weeks, it is quite possible to get good requirements from the client for that amount of work.

But, it is also possible to apply Agile methods to fixed-price projects. The main difference with traditional Waterfall projects is that you don't agree on a set of requirements, but rather on a set amount of effort to create as much of the desired functionality as possible.
The amount of effort will be based on the initial Scope of Work, but the client should be able to make changes to the Scope of Work as the work progresses without going through a painful Change Request process as long as the remaining effort doesn't increase. So, the client should be able to say "On second thoughts, I don't need Feature X. Can you do Feature Y instead?" and not see an additional bill if Feature X wasn't implemented yet and Feature Y takes about the same or less effort.

As Agile processes embrace the fact that requirement will change during the implementation, there is no point in trying to discuss detailed requirements before the project has been awarded. It is better to keep the discussion on the level of features instead at that stage. The detailed requirements will come when you are preparing to start working on each feature (or not, if the feature ends up being scrapped).


Evaluating a process is more involved than just looking at a high-level view of the process flow exhibiting only the happy path. Since it is just the happy path, there are substantially far more connections where information and product material flow in reality so no credible judgment can be made here. Further, you need to examine the actual work within the process and the results to analyze and measure the seven deadly wastes of a process. That also cannot be done evaluating a high-level, happy path process flow.

Finally, there are also probabilistic attributes of each process step that needs to be measure and analyzed, not exhibited here--for example, duration of each step, step failures, defects produced, costs, revenue, etc.

So my advice is to build a real process flow, capture the attributes, maybe simulate if you have the tools, observe the process in action, identify where you have some of the deadly wastes, adjust the process, re-measure, and on and on.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.