Architectures and Design Patterns · News from the Web · Team Leadership · Thoughts from Real Life

Lessons learned from the field: listen your Stakeholders

Engineers with leadership roles supposedly work with stakeholders to collect requirements and then lead the developments accordingly. Often, the set of stakeholders and requirements are not clearly defined and Engineers struggle to lead effectively the efforts in the right direction, within the expected timeframe. Such struggles, not rarely, bring to failures: how many times a project gets terminated in spite of quality deliverables? And, a follow-up question: why this happens when deliverables are there? From the field experience, deliverables are not the only evaluation criteria, and often come after other ones: for example, the level of satisfaction of your stakeholder about the work done with respect to the initial expectation. In a hierarchical organization, normally Business and Functional Analysts are primary stakeholders for any project: the work of the two roles is supposed to translate the business needs into functional requirements, and for customer-facing products this means product requirements. Not always organizations are organized in a structured and hierarchical way, let’s imagine for example the case of agile teams asked to build green-field technologies and then products. In such cases, Business and Functional Analysts are not involved in the loop, instead the Lead Engineers are asked to collect the requirements from the stakeholders and, as clear from above, this is not an easy task to deal with.

Hereafter, a few lessons learned from the field are discussed, and a few advices are then highlighted with the aim to help Leads out there to be more effective in driving the success of their projects, even within unstructured contexts.

 

Who are your stakeholders. Let’s start with this question: who really are your stakeholders? As clear, this is a key aspect in the guest for success, because missing some of your stakeholders would mean missing some of your requirements, and in turn missing one or more features in the final deliverable. One of the first question for a Lead Engineer then should be: who are the stakeholders? Follow-up questions should be: from whom the requirements should be collected? Who is going to take the final decisions about the project? Who is going to benefit from the services implemented? Who is going to lead the advertising of the services/product/proof-of-the-concept? Who is going to be involved directly or indirectly into the life cycle of the project itself? Such set of questions should be enough to identify a set of actors to interact with, to make sure that the preliminary analysis of the problem set, as well as of the support technologies are carried out effectively: a slight deviation from the expectations, even in the preliminary phases, may be amplified in the execution phases and hardly impact the perceived quality of the final deliverable. Perceived quality, why is it so important? A viable answer might be: no matter the concrete quality of the deliverables, the perception of it from the stakeholders’ perspective is hardly influenced by the initial expectations.

 

Which are the requirements. Initial expectations, this is a good point to start with. It is very important to get as soon as possible in the analysis phase – remember, in the execution phase would be too late – a narrow understanding of the stakeholders’ expectations. Such expectations define a set of wishes, or a sort of wish list maybe from the most important actors of the overall process: as said, often the stakeholders are asked to the call for the prosecution or termination of the project. Once built the wish list, or better the set of desired high level traits of the deliverable that the project is expected to work on, the next crucial step consists in translating the items in the list into as many high level requirements.

A high level requirement might be seen as a key word defining or even representing a i. technology, ii. a procedure, iii. framework, iv. scheme of interaction, v. algorithm, or whatever else might be brought in, directly from the context. Requirements at such a high granularity are extremely important, because they allow to avoid narrow focus on any problem set: problems to be solved should be in sync with the big picture, and not deviate too much from it; for example, looking on a daily basis to a list of higher level requirements is going to likely help in avoiding a blind and deep focus on finding the best solutions for a set of engineering problems which is often only a small part of the overall demand.

 

How to meet the expectations. In part, this has already been discussed above: do not deviate too much from the wish list, or from the big picture which is a formed concept in the stakeholders’ mind. And, once again: look at the big picture as at the final goal.

Translating the high level or business requirements into broad functional requirements might not help; more than ever, in these uncertain circumstances, the translation from business requirements to functional requirements should be precise, systematic and not open to any interpretation: even a word may be impactful, because it can bring the team to an execution path which deviates too much from the formed expectations.

That being said, precisely execute with an iterative approach, showing up gradual progresses on the execution, might be beneficial for the faith of the project: double- and cross-checking the intermediate deliverables, within an agile context, might be a key aspect for the success because the same stakeholders asked to give a call at the end of the game are involved in intermediate decision processes. Operating like this is going to likely reduce the chances to ‘take the tangent’, and to better stick to the wish list, correcting it sooner in the process in case of any small fault.

 

Conclusion. Leading efforts is not an easy job to accomplish, and this is fairly true in agile contexts. Lead Engineers may have hard times to coordinate the efforts, respecting the original expectations, set by the stakeholders as formed wishes in their minds.

Being systematic, disciplined and open-to-change is the way to go: creating a plan from the high level requirements, sticking to the plan and being open to deviate from it in case of negative feedback are the key factors to successful execution, even in agile and not well structured contexts.

To the Lead Engineers: do not stick to your design, be able to update your design as your plan moves forward including the feedback, and in case of push backs do not try to push back but be open to listen and smoothly react. Satisfaction, and compliance with the wish list of the final deliverable is what really counts.

LikeLessons learned from the field: listen your StakeholdersCommentShareShare Lessons learned from the field: listen your Stakeholders

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s