Requirements engineering and user involvement and their impact on project success with Daria Polończyk and Paweł Pukocz

Our guests, Daria Polończyk and Paweł Pukocz, not only talk about a clear statement of requirements and user involvement, but also discuss two most popular project management methodologies.

Our Guests:

Daria Polończyk – Analysis & Desigin Manager at Future Processing. She’s responsible for developing business strategy while meeting operational high level goals and defining depertment’s detailed objectives. Daria is an experienced Business Analyst with a keen interest in software design and IT Service Management.

Paweł Pukocz – is Future Processing’s Line Manager & PMO Member taking an active role in the ongoing enhancement and development of company’s Team Leaders. Paweł has a lot of experience in software engineering and managing the development teams, but also in mentoring and supervising field.

Michał Grela is Future Processing’s Relationship Manager, working within the marketing department to establish and nurture relationships with prospective customers and expand the company’s network of contacts. He strongly believes that business is about people and that, at the end of the day, it’s all about Human-to-Human rather than Business-to-Business.

Michał Grela (MG): Hi, my name is Michał Grela. Welcome to IT Leadership Insights by Future Processing. I’d like to start this episode by reference to a Standish Group report. This report states that there are top three major factors that have the most crucial impact on the final outcome of IT projects and these factors are: clear statement of requirements, user involvement and executive management support. But before we will take a deep dive and delve into details, let me introduce my guests today, Daria and Paweł. It’s great to have you here. Please tell us something more about yourself.

Daria Polończyk (DP): Thanks for having us. I manage the Analysis and Design Department at Future Processing. It’s a team of extremely creative and highly skilled professionals from area of user experience design and business analysis. We help our customers with their digital product design, sometimes the whole service design. On the other hand, we support projects’ delivery by requirements engineering and user experience design.

Paweł Pukocz (PP): I work for the Project Management Office at Future Processing where we monitor our projects, continuously work on improvements for our delivery process, also introduce changes to our organisation and develop our project managers and team leaders.

MG: Thank you. Let’s start this discussion with the first factor mentioned in the report, meaning the clear statement of requirements. What can we do to maximise the positive impact of this factor, of this element? How can we use it to maximise the efficiency of the whole project? How do we start?

DP: Well, requirements engineering is a complex process. There are some steps you should take before you start development. First of all, you should build a solid foundation for requirements – detailed requirements engineering. I mean, you should bring in answers to key questions such as ‘what benefits do you expect from your project?’, ‘how will you measure them?’, ‘what are your business objectives?’, ‘are they clearly defined?’, ‘what are key dates?’, ‘what’s behind them?’, and so on. All of this should be summed up and shared among all your team members if you want them to start developing your project in the right direction, just from the beginning. Next thing important to do is a stakeholder’s analysis. You should distinguish groups of people who has an impact on your project outputs or people who your project impacts on.

PP: Yes, and this stakeholder analysis is part of the project management, in general methodology. And in the Standish Group report, there is also the third factor is support from the executive management. So we also include stakeholders, plus the stakeholders from the customer organisations, so the people who have any influence on the project and will benefit from this project. So, moreover, the stakeholder analysis also gives a feeling for the development team in further phases of the project that they know the stakeholders, they know who plays what role in the system, who benefits from the system, et cetera.

DP: And how to communicate with them, also.

PP: Yeah, and it’s an important thing that, it’s makes the communication easier.

DP: From requirements engineering perspective, we basically need a group of key stakeholders. I mean, people who have the proper knowledge and authority to give us pieces of information for requirements engineering and also make the key decisions for the projects. If you have that right people in your project, you can start with dealing with requirements. Usually we start with a high level vision of future solution and then dive deeper into details. From now on, you can proceed this requirements engineering in a few different ways, depending on, for example, project methodology.

MG: Oh, I’m glad that you brought that up. Two most popular methodologies, the Agile versus the Waterfall. How does each of these methodologies, how are they affected by this approach?

DP: Starting with the Waterfall methodology, it has its drawbacks, especially in terms of reacting to changes in a business environment. But, of course, sometimes you need fixed budget for the project. And in such situations, you need to discover as much requirements as possible before you start development. To do that, we usually work interactively with our key stakeholders by conducting workshops where we dive deeper into details, and it’s extremely important at this stage to have a good understanding among the participants. To do that, we use visual methods of representing information that was agreed on during the meeting, such as drawing business processes, preparing a map of requirements, drawing use case diagrams and also paper prototyping. Yeah, if you have all this information, you will have an input for requirements specification, which then you can use as an attachment to RFI. And if the requirement specification is not clear enough or not detailed enough, you will get the answers with either unnecessary buffers for unknowns or with a narrowed-down scope, which obviously won’t answer all your business needs.

PP: And the Waterfall, it is very important to have these requirements ready and with the good quality at the beginning because based on those requirements, the vendor must provide an offer. So, better requirements results in a better offer, more accurate offer, also with better plan and schedule for the project. Also, Daria mentioned about the meeting workshops with the other stakeholders that results in also the stakeholders analysis, but during those meetings, there are many discussions about the whole project. So you can use insights from these meetings to risk management, to stakeholders analysis, maybe some other part of the project management.

MG: That’s about Waterfall. But it is the Agile that’s the most popular way of managing projects. What about it?

PP: Yes, Agile is nowadays common way to delivering business value to the customer. The major two factors, two important factors in Agile are adopting and accepting the change. And in this approach, a Business Analyst prepares backlog for the first one or two sprints and also the business goal, the high level plan and business, let’s say roadmap for the project, which is later used by the development team. And during the development cycle, the BA is still in the process and works on the, continues to work on further requirements. So in this approach you can start right away. Just prepare this backlog for the first phase and continue development.

MG: Thanks. Daria, before you’ve mentioned that this clear understanding and speaking the same language is very important. How do we ensure that? How do we make sure that everybody speaks the same language? How do we ensure that all of these requirements are well-defined and translatable?

DP: Yes, the first aspect can be the understanding during the workshop I mentioned before and improving it by using as much as possible visual methods. Next thing that from my experience is very important is a glossary. Because if we work with different domains, sometimes the simple word can have definitely–

MG: Yes, that’s true.

DP: Some different meaning. Also according to understanding of requirements for your development team, the important thing is to bring acceptance criteria along with requirements. Because thanks to acceptance criteria, your team will know how you will verify if the requirement is achieved. And last, but not least, I would say a user interface design. Because when you have mock-ups of your interface, you will have the most straight way of showing what you expect from area of cooperation with the user.

PP: Also I would like to underline the importance of the Product Owner role in the whole system. This person translates the user needs, the customer needs to the requirements, which is later used in the development process. And this person should be available, the availability of this person should be high. It must be. This person should be present during the whole development cycle. I remember one situation where Product Owner was dedicated to our team on the customer side. However, he was not available enough and that resulted in poor requirements, poor backlog. Also, it was frustrating for the team because developers didn’t know what to do, in which direction they should go.

MG: As a blocker?

PP: Yeah, as a blocker. We proposed the customer a kind of Proxy Product Owner, so a Business Analyst on our side, who was the main point of contact between the team–

MG: That’s a great solution.

PP: And the customer. And it finally lead to the better requirements and backlog full of the good quality items, so the development returned to its previous capacity quickly.

MG: Let’s get to the second factor from the report, the user involvement. Today, at the end of the day, you want a solution that’s usable, and that people like to engage and interact with. And that’s the goal of stakeholders today mostly. How do we ensure that’s covered?

DP: I would say that the more your project success depends on user usability and attractiveness for future users, the more important it is to keep them close during the process. To do that, you should define key groups of your future users and research their needs, their pains and expectations from the system, and then move to designing the system for them according to user-centered design methodology, and according to business requirements, of course. We had the pleasure to design the solution for heavy industry, lately, few months ago. One of key objectives of this project was to bring an optimisation for business process and also lower down the cost of training for users. After we defined the groups of users, we decided to go to see how they work on a daily basis. And it occurred that they work in poor lighting with gloves on, using heavy tools and the software was supposed to be designed for tablets. So this is why it was extremely important to ensure the best possible usability for this solution. And now I can say that, if we hadn’t experienced their true difficulties in their work environment, we wouldn’t have had a chance to design a solution that will truly support them.

MG: That’s true, and it does sound like added value, but it also sounds as extra costs, extra effort, extra investment at the very beginning of this journey. Is it worth it?

PP: It is, I would rather say that this extra effort is our investments. Because you spend time with your client, with the stakeholders. You discuss the project scope, you find some risks and chances for the project and it is done before the project. So, and the later we discover change in the project, the more expensive the changes. So yes, it’s worth doing it, I would suggest that this part shouldn’t be omitted and I would recommend this solution.

MG: Still, it sounds great, but sounds reasonable mostly for bigger projects. But what about small investments where you like quickly want to check the concept of a particular idea, how would you address that?

DP: In such challenges and projects where you have smaller budget at the the beginning, we recommend conducting a small workshop where you just discover the high level vision for the future solution and define the MVP, which stands for Minimum Viable Product, which is a core functionality for the future solution. And at this workshop you can dive deeper into requirements only in the area of this MVP. It’s interesting that you don’t have to involve a development team in order to create a Proof of Concept. Because if you have User Experience Designer in your team, you can prepare a clickable prototype, interactive, that will give you a look and feel of future solution and you can take it and have feedback from your investors and from the market.

MG: Okay but what can go wrong? What are the risks?

DP: Well, one of the biggest threats, is for example, not involving a key stakeholder. You can miss someone who should be included in your team. What else… Well, the requirements shouldn’t be locked and kept only in documents. You should talk about them and develop them if you want to have a good understanding along the project.

MG: Okay and what are the benefits?

PP: The benefits? You have clear and understandable requirements. You have some insights fore further project management like risk management, stakeholder analysis. Also you could have more accurate plan and schedule, if you ask the vendor, they should be able to provide more accurate details about the project, the workshops, those meetings, the time spent together builds positive attitude and loyalty from the stakeholders. So they feel important because you ask them for their opinion. Later on, it makes the communication easier with them, with the development team.

MG: And this feeling of being in this together a bit.

PP: Yes.

MG: What would be your best piece of advice for those who are considering this approach?

DP: If you consider running an IT project and you need a company that will develop it and deliver it for you, you should look for a company who will be your IT partner, not only supplier. I mean the organisation that will care about the business value you are expecting from this solution. Because having such a partner, you can also have, you will also have a advisor in terms of technology and achieving your business goals.

PP: My advice – if you decide to go with that approach, do not treat this phase only as an input for specification. Use all those workshops, those meetings and other activities as insights, as input for further project management.

MG: So it’s fair to say that better attention to requirements translates into better understanding of these requirements and this then translates to more efficient cooperation in the team and at the same time lower cost and less rework.

DP: Yeah, of course.

MG: Wonderful, it was a very insightful conversation. Thank you for joining us today.

DP: Thank you.

PP: Thank you.

MG: And thank you, our viewers for watching this episode of IT Leadership Insights. If you have found it useful, please don’t hesitate to share it among your social network and please do drop us a line if you would like to have a topic covered in one of the future episodes. That was IT Leadership Insights by Future Processing. Thank you.