A client recently posed this question (and 4 others) to us - the internal discussion regarding this question is interesting ...
[SM:]
a. Not sure what early means. Let’s assume the project is about to start.
i. I’d look for the skill set of the BA team
ii. Are they using a structure for gathering requirements (ie. something like the Process MeNtOR Analyst toolkit).
iii. Is a process of review in place?
iv. Are requirements to be signed off?
v. Is there sufficient time available for review and sign off?
b. On the other hand, what happens if the designer joins the project when the requirements are already ‘done’
i. I’d put in a review of the requirements before committing to an estimate. It is risk management
- Clarity, coverage, consistency
- Does it have all necessary elements: Functional, Data/business objects, UI, Business rules, non-functional
- For bigger requirements set: is there an overall structure to it that allows the reader to comprehend it and navigate it?
ii. Are the requirements “completed”:
1. Evidence of successful review and sign-off
2. Requirements are base-lined in some form and change control in place
3. Are outstanding questions identified (good)? Are the showstoppers (bad)?
4. Which requirements are still outstanding or expected to change? What is their impact?
5. If requirements still need to be defined – is there a BA available to handle this?
iii. General Requirements issues:
- Are the requirements in the form of a solution
- What assumptions are made? Are the assumptions known?
- Has there been some architectural feedback during the requirements gathering phase? If not – is it buildable?
- Who was involved doing the requirements? Users, SMEs or only BAs? This influences the risk picture
[JE:]
This step of any development process is all about gaining knowledge without detail level information of the solution. The key things we’re looking for are pitfalls, things that will bite us later on in the process. Every project is going to be subject to the classic forces: Scope/Requirements, Budget, Time. The information which can be gathered early in the process about the volatility of the requirements will partially dictate the choice of methodology. The budget and allowed time are usually better understood in terms of constraints.
All of that said, the next set of important parameters can be considered:
Stakeholders - Who has say and sign-off, who has design input. Finding these people early is important, especially those that are of a combative nature.
Hard limits vs. Soft limits - Knowing which restrictions placed on a solution are set in stone and which are a bit flexible can dramatically alter the nature of a project
Environment - On a technological level, what we’ve seen from recent projects is that providing correct development and build environment can make a major difference to the rate of a project. Having a well defined and implemented development (and deployment) environment is definitely worth the investment. In political terms it is important to maintain two key aspects of the work environment: People must be able to offer up new ideas and improvements to existing practice to be socialised by the team(s); People must not be made scapegoats of – there should be an environment which allows and rewards experimentation.
Dependencies - One thing I’ve personally experienced is getting a project 95% complete, and then spending months waiting for dependencies to be completed. Knowing what you depend on and being proactive about chasing them down can save a lot of time, or be a major pitfall if it’s neglected.
Pending changes to other projects (substitution, impacts) - As a follow on from the point above, if any of the systems you interface with has pending changes / work in progress that will impact on your project, you need to know up front so you don’t have to repeat work. The problem you then face is coordinating with all the other teams you work with, but if they don’t plan sufficiently ahead this may be impossible to avoid.
Available resources (staff, cash)
Time for research and to do POC work / spikes - We know from project experience that doing proof of concept work and trying out design ideas on a small-scale to validate them ahead of implementation can dramatically improve the quality of estimates and prevent a team from pursuing a design that later proves to be flawed. Whether this time is allocated as part of particular projects or to a centre of excellence to conduct ongoing research is up to the organization, and it’s ability to communicate the results.
Pre-existing commercial arrangements / alliances that will impact
[SW:]
What are the riskiest areas of the project (technical, political, external, etc)? What can be done to mitigate these risks?
[LC: ]
I think this is covered relatively well in MeNtOR. In the solution and system architecture templates, there are sections that force you to think about driving factors of the solution from many different angles and there are sections that makes you think about the design in many technical aspects.
I can't remember how much guidance is provided in the process unit text. If not, then it is an opportunity to add more there, such as what Jon mentioned.
[MC: ]
SM touched on the content on the requirements, but I’d like to put a slightly different slant on it. While the content is important, I think more importantly is the process by which they were reached. Assuming the architect has been brought in after the requirements modelling has taken place, the first thing to verify is the process used to reach the written requirements. Too many times I’ve seen projects burnt by requirements that looked ok on the surface, but once the domain was better understood a couple of months down the track, it became obvious that there were a lot of cracks in them.
So when looking at the process, have they started with the business problem, worked through the business scenarios, developed and used a common language, written requirements that are system agnostic and involved the architect in deciding where functionality should reside (eg. System A, System B, Manual Process, 3rd party service etc). Be very wary where a solution has been spec’d instead of a business problem. Eg. “We need a form template builder that lets you put business entity attributes on a page using these controls and merge in data” is not as good as “We need to be able to have users fill in forms online, showing them data we’ve previously collected”. The former is a solution, while the later is the real business problem.
In short, if the process followed was good, they have a much better chance of success. If not, then you’re likely to find issues down the track. In this case, my first move would be to revisit the steps of the requirements gathering process that were skipped, then map what you do have back to make sure it all fits together cohesively.
Carl Rogers - Principal Consultant & Process Development Architect