How to Make the Most of Project Process Descriptions
Management’s policies on definitions and documentation of project processes is the kind of thing that could convince you that Dilbert’s author (or Dilbert!) may be employed somewhere in your office. However, if you approach it in the right way, project process descriptions will no longer be a tiresome administrative task but can be used to your advantage. First of all, they can be used to clarify expectations in the project team and with other people involved in the project. Second, you will have valuable input for defining and estimating project tasks.
The purpose of this article is to discuss what the business analyst can achieve by taking active part in defining and describing project processes for requirements development and management.
CMMI: A Process Focused Project Model
Capability Maturity Model Integration (CMMI) consists of a number of process areas. Some of the areas are defined on an organization level and set the framework for the individual projects, for example Organizational Process Focus. Others are defined within the projects and the content will depend on the characteristics of the project. Two of the relevant process areas for the business analyst are Requirements Development and Requirements Management. The better the process areas are mastered by an organization, the more mature it is. A mature organization is able to deliver what the customer needs at the time and price estimated. The CMMI model gives you guidance – described as practices – on what to remember and to consider when defining processes within the process areas. What you do when defining a project specific process is describe how you implement the practices from CMMI. This means that you can use any method you prefer, as long as it is compliant with the practices. For example, in Requirements Development one of the practices is “Elicit needs” but this can be done using both an agile or a waterfall approach.
CMMI basically applies common sense in a structured manner. The main point is this: define and plan your process in advance, work according to that process, adjust it along the way, and learn from your experiences the next time around.
What to Include
First you describe the purpose of this particular process. You will do yourself a favour by focusing on the characteristics of the project instead of describing the overall purpose of developing requirements. This will help when you need to determine which methods to use. Your process description should contain the following:
Roles and Responsibilities
Who is involved and how are they expected to contribute? Who has the final word when it comes to prioritizing, accepting and approving requirements? This is important for the obvious reason that stakeholders and end-users will know what is expected of them. But there is another important point. Because you have identified up front who is supposed to participate, you will have everyone involved on equal terms from the beginning. A consequence of not doing this is that you could find yourself favoring groups of end users or stakeholders that are the loudest, are closest geographically to the development team or are in best standing with top management. This can be avoided by identifying your participants at the start and you will develop a “democratic” process for developing and handling your requirements.
Activities or Tasks to Be Carried Out
This is basically just outlining what to do in which order. For example, which method(s) do you intend to use when eliciting needs and requirements? How will you document or model your requirements? When are you done developing requirements? It is a good idea to also define entry and exit criteria for each activity. That is, what is needed in order to perform the activity and when do you know that you are done? This will not only ensure that you achieve what you set out to do but also that you do not overdo it or get lost in details.
How to Approach the Process
The extent of this work will depend on many things. For instance, how experienced you are and how well you know the other people involved. If you have done this many times before, it will just be a formality ensuring that your activities are in line with this particular project and setting expectations straight with the project team, stakeholders and end users. This will probably be something you can sketch out on a napkin during lunch. If you are new to the field, you need to consider how to incorporate best practice or theory from the field.
Create a First Draft
If you are new to the organization or the business area this is a good opportunity to ask around about previous experiences with the same kind of projects, find out what you need to pay special attention to, the relation between the stakeholders etc. This is, in other words, the perfect chance to “stick your finger in the ground”.
Review and Acceptance from Project Team
Before you communicate how you intend to approach the requirements development, it is important to have commitment from the rest of the development team. Also, if you don’t know the team members, this is a way to clarify roles within the project team. When reviewing project processes, be aware of overlap between different process areas. This can lead not only to duplication of work but also to unclear responsibility between project participants. For example, when working with requirements management, you have to be aware of the change management process and make sure that the two process areas are coherent. How to suggest a new requirement to the project will be described in change management, while how to archive rejected requirements would be included in requirements management.
Acceptance from Stakeholders and End Users
It is important that whoever is paying for the party agrees to who should be involved and the extent of their influence. This is probably the closest you get to a guarantee of commitment to the final result of the requirements development. When this is clarified with the project’s sponsor, you can communicate to your stakeholders and end users how you intend to involve them. Acceptance from everyone involved in the requirements development regarding the premises for the task, their role, and when they are expected to contribute is important for full cooperation. When this is settled in advance, you can focus on the actual objectives of the project in the requirements development activities. A good idea is to create a “start kit” for the people you cooperate with on this. It does not have to be more than a brief presentation about the project, their role in it and a list of the planned activities that they have a stake in. You can use this to elicit cooperation by presenting it at a meeting or simply sending it out for information.
Why Even Bother?
The issues described in this article will most likely be issues that all business analysts consider to a smaller or greater extent, more or less explicitly. So what is the point of documenting the processes you work by? First of all, in evaluating your processes you will define learning points and experiences. This makes it easier to improve the quality of your work both in the course of the project and in your next task. Second, it ensures that the methods you choose are tailored to the specific project. No two projects are the same which means that no two approaches to requirements development should be the same. Also, with growing globalization, projects will to a greater extent involve people from various cultures communicating in English, which is not necessarily their native language. This is at least true in my corner of the world, and this increases the need for talking about how we work and why. And how we work and why we work like that is basically what project descriptions is all about.
References: Mary Beth Chrissis, Mike Konrad and Sandy Shrum: CMMI, second edition, Addison-Wesley, 2007
The Texan CMMI guru Tim Kasse has written several books on how to apply CMMI based on his experiences in teaching and assessing CMMI in companies all over the world.
Line Karkov is Master of Science in Information Technology from Aarhus University, Denmark. Since 2007 she has been employed as a business analyst in Danske Bank Group’s internal development department. She works primarily as an internal consultant on large development projects. She teaches internally in development processes. The Danske Bank Group is the largest financial enterprise in Denmark and one of the largest in the Nordic region.