Creating success in any IT project comes down to a few vital insights. We believe that complex products and services need well-crafted and methodically engineered requirements. We also believe that projects need to be organised to promote collaboration and reduce risks. It may sound trivial, but reality shows the opposite. Implementing sound work-flows, managing deliveries through Baselines, promoting collaboration between stakeholders, are all vital steps on the path to success. Below, we have outlined in more detail, what we believe are these key factors:

Understand what You build

  1. •You are building knowledge, about: technology, business models, organisations and processes.

  2. •Documents, requirements and software are only representation of that knowledge.

  3. •Knowledge cannot be transferred between brains, not from customer to project, not within the project. Knowledge is constructed by each person, and you need to organise your project around this “knowledge construction” approach.

Organise Your project

  1. •Promote collaboration and reduce risks.

  2. •There are three very important teams and functions in your project: Requirements Engineering, Test Engineering, and Configuration Management.

  3. •Besides these three vital teams, the project needs a Software Engineering team, a Quality Assurance function and a Project Manager as well. Instead of organising projects into product domains, organise the project around these teams and functions.

  4. •During project meetings, make each team report progress and risks according to their responsibilities.

  5. •When you report a risk, also suggest a solution. No one understands the problem better than you, even if you don’t have the resources or power to do anything about it. Managers can help you, but they will seldom suggest a solution.

  6. •One effective way to reduce risk is to execute the project in increments. Set the scope for the increment, develop the requirements, design, implement, test and deliver. Use Baselines to manage requirements and deliveries.

  7. •The length of each increment can vary. In the beginning, it’s not unusual that the first increment is six months, but as the project gets up to speed, the increments can be as short as three to four months. Some projects have increments that are as short as 7 to 8 weeks, but it’s hard to write requirements, make reviews, code and test in that time frame. You will soon find the rhythm that is right for you.

Write Requirements

  1. •Write a complete Requirements Specification. Don’t be satisfied with developing use cases. People need to read words (complete sentences) to understand, and they need a context for these requirements. You don’t need to write all requirements at once. Take it in chunks (increments) and stuff them in Baselines.

  2. •Never ever use Powerpoint instead of writing a Requirements Specification. Powerpoint can be used as a tool for communicating key ideas, such as the scope of an increment, but not as the only tool for documentation of requirements or design.

  3. •Involve all stakeholders. The Requirements Engineering team cannot talk to all people all the time, but they need to talk to persons that represents business models (sales and marketing), the organisation (support, customer care, IT and infrastructure, management), processes, and technology.

  4. •Let your stakeholders review the requirements. If you have a real customer, let the customer review and give you feedback in face to face meetings. Give the customer a new version of the RS each or every other week.

  5. •If you don’t have access to a real customer, you still have stakeholders in the project. Let these review your requirements.

  6. •A Requirements Baseline can contain as little as 30 requirements, but it can also contain over 100.

Define and execute Your process

  1. •Define what competencies you need to be able to nail the requirements. You need people who understands and can reason about:

  2. •Business models

  3. •Organisational issues

  4. •Process issues

  5. •Technology

  6. You also need people with the following perspectives:

  7. •Software Engineering

  8. •Test Engineering

  9. •Usability Engineering

  10. •Put together your team. People will work with one leg in the Requirements Engineering team and one leg in the Software Engineering team, or one leg in the Requirements Engineering team and one leg in the Test Engineering team. If your whole project consists of ten people, your Requirements Engineering team should consist of three or four.

  11. •Never put the customer in the Requirements Engineering team. You need to be able to put all issues on the table for a candid discussion, before you present a solution to your customer. If you put the customer in your team, you cannot have this discussion. There are certain things you don’t want to communicate to your customer before you have made up your mind.

  12. •Plan your work. Decide on how you are going to do your activities and when. Negotiate the plan with the rest of the project and communicate it to all your stakeholders. You may say to the customer: “We want a face to face meeting once a week, on Thursdays. You will have a new version of the RS two days before that meeting, and we expect you to have relevant comments on its content. We will write Minutes of Meeting on our discussions, and we will correct the issues we have agreed upon to the next meeting.”

  13. •Meet the customer. Agree on an agenda with the customer before the meeting. Decide on who should attend. All stakeholders cannot attend all the time. Some meetings are devoted to Business processes, some to technology, others to support. Make a preliminary planning together with the customer: “At this meeting we would like someone from Sales to be present. The meeting after that we need to talk to someone from Customer Care.” Write Minutes of Meetings. You must be able to trace all decisions to a document or person.

  14. •Analyse requirements with regard to risk, cost, and priority. Move requirements to later Baselines, if you feel that things need to become clearer, before you can decide on them. Involve your stakeholders in this discussion.

  15. •Establish the Requirements Baseline and make the customer sign it. The Baseline is now the formal foundation for coding and testing activities. Coding and Test have started long before the Baseline was established, but now changes will impact schedule or budget or both. The project is able to charge extra for making these changes. Manage changes to the Baseline by Change Requests.

  16. •Collect and analyse metrics. How much time do you spend in the process? How many requirements do you baseline? How many requirements are changed in Baselines. How does the write-review-meet-correct-cycle look like? Can we speed up the cycle or will that result in more problems later on? Are we getting too many or too few issues from our customer? Maybe they don’t understand what we are doing?

Manage Your configuration

  1. •Develop a Master Configuration Index (MCI) that contains all Configuration Items (CI) in the project. The usual Configuration Items are: Documents, Baselines, source code, executables, and Installation Packages.

  2. •Some common Baselines are: Contractual Baseline, Requirements Baseline, Development Baseline, Test Baseline, and Delivery Baseline. You may have other baselines or name them differently.

  3. •Implement a Change Request procedure. This procedure is only valid for changes of an established Baseline, not on work products under development.

  4. •Put together a Change Control Board (CCB), consisting of the project sponsor, the Project Manager, and maybe the customer. Other stakeholders can participate on as-needed-basis. When Baselines are up for change, the decision is taken by the CCB; but they need input from other stakeholders, so each meeting must be prepared in advance.

  5. •Use a Software Configuration Management tool (SCM) such as CVS, Perforce or Subversion. Use it for documents as well.

  6. •When asked, NASA said: “If we had to choose between Project Management and Configuration Management, we would choose CM every time”. That’s how important CM is.

  7. •Never ever make changes on your own in the project. It may be easy for you or your group, but it could hurt somebody else really bad. Some of the worst examples in history are Apollo 13 and Ariane 5 (Flight 501).

Train people

  1. •Project members need to be trained in process activities, in writing requirements and in managing these requirements.

  2. •The single most common failure for technical projects is:

  3. •Not having a common view on how to run the project;

  4. •Not having a common view on what the project develops.

  5. •Training people solves the “how to run the project” problem. Writing requirements solves the “what the project develops” problem.