Feature Driven Development

The start of a new project is when the most fundamental decisions are made. These decisions will impact dramatically on the project from that point onwards setting it on a sound and low risk path or pointing it towards a path of difficulty, frustration, spiralling costs and even collapse.

These fundamental decisions cover things such as the project objective (assuming there is one), the business expectations, how much the company is willing to invest and most importantly, who is involved in making these decisions. Having the right people working on the project and making these decisions will give you the greatest chance of success, the wrong people will guarantee trouble.

The problem is getting the right people onboard and taking into account "the human factor" is rarely examined or considered at the start of a project. We all know when someone is making a positive contribution and equally a negative one, but how often is this considered before the project starts? This article covers how Process One looks at the human factor and provides and opportunity to deal with it upfront before it becomes a major problem.

Commitment
To start Process One, the right people need to be present, a facilitator, the chief object modeller, the project owner and the domain expert. It requires that these people are available and can commit time to creating the overall model over a series of modelling sessions. If it's hard to get everyone to commit to be at the modelling sessions, then you've got a problem before you've even started. Getting the model right is critical to the rest of the project. If you can't get people to commit to getting this right, how committed are these people likely to be when the project is in full swing?

If you can't get everyone together at the start of the project to make sure it starts off on the right track, it's not likely to get better down the track. Those that don't commit their time are basically saying the project is not important enough. Which, from a business perspective, might be the case, but from the project perspective, it states loudly and clearly that the project is at risk before it's even started. Without a commitment from all parties, when problems arise (as they inevitably do), it is all too easy for people to say "not my fault" and avoid blame or responsibility.

Simply put, if people can't commit time upfront, the project is at risk before it's started.

Roles & Responsibilities
Process One defines a number of roles and responsibilities. This re-examines individual commitment and provides a chance to see if the right people are playing the right roles.

For example, on the football ground, every player has a position to play (ie. a role & responsibility). In playing their role, every move is visible to the coach and the rest of the team. If the player isn't doing their job everyone knows about it and something can be done. In business, this close examination rarely happens and people can play a role that they may not be well suited to. It is a harsh but true reality that just because someone has a particular job title, doesn't mean they are good at it.

In assigning specific roles and responsibilities, Process One forces individuals to play their role as a part of the group. It is not intended to expose people but it becomes very clear who is good at what, or not as the case may be. This provides a great chance to make sure the team that is going to be responsible for building the project has the right players in the right positions.

Of course, that doesn't mean that you'll always be able to get the right person playing the right role, politics will have a large hand to play in that (especially if it shows that someone more junior is actually better than someone more senior). You can't guarantee that you'll always get the best person playing the role, but at the very least, you'll be aware of the strengths and weaknesses of the team and manage it accordingly.

Buy - in
Process One is a group activity. It gets everyone involved in the decision making process. The value of this isn't obvious during the modeling sessions but will be later down the track when the project is underway.

It is a common complaint that management make decisions that affect their staff without consulting those directly affected. The decision itself is not the issue, the decision might be the best decision given the circumstances but if the people it affects have no say in the matter, they are likely to reject it by failing to support it. It may not seem like it on the surface, the staff might appear to be happy with the decision, but deep down they don't like it and cause the decision to fail by not supporting it.

On the other hand, if staff are involved in the decision making process, understand the issues and difficulties involved and are given the chance to have their say, they are far more likely to support the decision. That doesn't mean they have to like it, but they will be more likely to support it. The same goes with decisions made in the modeling session. Rarely will everyone agree on every point and at times compromises have to be made. If everyone is a part of the decision making process, even if they don't get what they want, they are more likely to support the decision and the project as a whole because at least they were involved.

The Facilitator
It is the Facilitator's role to get everyone together and ensure modeling sessions are run effectively, efficiently and achieve an outcome, ie an overall model. This requires a good understanding of human nature to be able to manage public and private agendas, power struggles, basic time management (eg. not letting meetings drag on too long) and keeping things on track. A Facilitator must ensure that all voices are heard, not just the loudest, that the session doesn't get bogged down or side-tracked onto interesting but irrelevant details.

The Facilitator plays a key role in achieving a meaningful outcome. The Facilitator must be objective and have the outcome as their key priority. Process One defines and requires this vital role. It ensures that someone is responsible for keeping things on track and that sessions don't devolve into talk fests or are dominated by a single person. The Facilitator helps to bring the group together, to bond and form the team that will then go on to build the project.

The Domain Walkthrough
Before modeling starts, the domain expert is required to provide the group with a domain walkthrough, ie explain how the business operates. This serves a number of valuable purposes, not all of which are obvious.

The first purpose is to provide a common view of the business to the people that will be building a system to help the business. It ensures an understanding of the situation which helps to ensure decision made down the track are informed decisions. It is too easy for decisions to be made with a lack of understanding that are only revealed when someone tries to use the system and it doesn't make sense, by which time it will cost far more to fix than if the decision was better informed.

The second purpose is to review how the business operates. Just because a business process works in a particular way doesn't mean it makes sense. Sometimes business processes evolve over time and become more complicated than they need to be. Building a system to reflect an inefficient process can be a case of pouring in good money after bad. Sometimes it is better to not start a project until internal business process issues are resolved. Otherwise, at the very least, it provides a good insight in the scale and complexity of the project.

The third and final purpose goes back to roles and responsibilities and exposing who is right for the job. The Domain Expert might be the person with the most knowledge of that part of the business but may not be the most appropriate person to be making decisions. If they are able to talk about the domain in a clear and concise manner, answer difficult questions without becoming defensive, then it makes it easy to for everyone to get a good understanding of the domain. If the Domain Expert is unable to give a clear picture of the domain, either the domain is very complex and the project will be harder and bigger than expected, or the Domain Expert is not the right person for the role and it will be hard to make informed decisions.

Getting a clear and precise picture of the domain upfront is important in making sure the model is accurate. Mistakes in understanding at this point will be compounded over time and be far harder and more expensive to fix down the track. If you can't get a clear picture at this point, you're exposing the project to serious risk.

Language
When creating the overall model, the language used, ie. descriptions for tasks, processes, items…etc used should be those used by the business, ie. the terms used in the domain walkthrough. This seems fairly simple but it's surprising how easy it is to start using technical terms that might be understood by those in the software industry but don't mean a hell of a lot to the business who the project is supposed to be for. When this happens, assumptions are made and not tested. The developer will describe something in technical terms and the business won't question it because they assume the developer is correct and are too scared to ask stupid questions like "what does that mean?".

A common language, the language of the business, helps to ensure that everyone on the project is talking about the same thing. When jargon comes into play, communication starts to break down and assumptions are made that are never tested. Process One helps to reduce the risk of this by ensuring the language used in creating the overall model is that of the business which sets the language for the rest of the project.

Conclusion
The human factor is the most influential in any successful project yet is often given a low priority. In Process One, the human factor is addressed on a number of levels. It doesn't guarantee success but does expose the risks and help clarify the situation so at least informed decisions can be made. And most importantly it addresses the human factor at the start where it can have the greatest impact.