Managing Stakeholders:

When managing stakeholders keep the following in mind:

Who are the stakeholders? 

You need to identify all of the stakeholders at the start of the project or you may have additional requirements revealed in as stakeholders are added after the project has already started.

What are their requirements?  

You need all of the requirements at the start of project (and what requirements which will not be included). Without them your project may have delays, cost overruns or possibly fail.

How to communicate to them during the project? 

This needs to be defined at the start of the project. Determine what the frequency of communication and what it will include (typically it is concise and brief and focused on progress and value). If including project metrics, all measures of the project elements must be meaningful to the project stakeholders.

Keep the project vision visible! 

Keeping the project vision accessible allows everyone involved in the project to stay focused on what's important. The benefit is that it helps reduce the chance of scope creep.

Keep them involved!  

It is important that during the project the stakeholders are kept involved by things such as: being a risk response owner, engage them in problem solving, reviewing new requirements and creation of lessons learned.

What is done? 

Stakeholders need to agree what done looks like. If they don’t, the project may be off track before it starts.

Movement to Agile software development…

Recently at my organization there was a need for a new piece of software and a very short timeline to develop it.  The Executives came to me about making sure the project was completed on time.  I had 2 requirements before I would accept the project:  1. I would not use our Software Development Life Cycle process (SDLC); 2. I would manage the project with a co-manager who heads up our network systems group.

So why would we ditch our predefined SDLC process?

Our SDLC process has many excellent documents and procedures on the process, but the issue with using it for this project was a short timeline and we wanted to review the software as it was being built (which helped us determine those requirements that we were not sure of at the start). So I wanted to move forward with an Agile method.

Why have a co-manager?

I wanted this so we could develop our own documentation templates that we could use for future projects and hopefully after several projects we can prove to the executives that an Agile method is an acceptable method for us (we would need to calm their fears about FDA reviews).

Let’s get it started!

We started by first selecting a team of expert content users (the stakeholders).  Many times I’ve seen software development projects where the executives sit in each meeting.  Why?  I understand why they are there for the kick-off, but if they are not going to use software (so they are not expert content users, but they are a stakeholder) we spend a lot of our time in meetings explaining how things work to them.  Having the right team is critical for this process to work (Jesse Fewell recently wrote an article about this: Tail of two teams).

Next we had our kick-off meeting where we told stories about what we wanted the software to do.  From these stories we pulled out the requirements and came up with 3 stages (or sprints) for the project.  The requirements were documented within their stages and we also included acceptance testing within it.  We did not put this into a burn down chart (improvements for next time) and I recently read an article about making screen shots to add to your stories (link)

You want to meet again?!?

The key to making this work is frequent face-2-face meetings for the team to report what they have done and what they are doing next (helps to keep people on track) and this is an opportunity for show and tell of the software.  Agile methodology recommends daily meetings, but we stuck with meeting 2-3 times a week.   During these show and tell times some new requirements came out and we determined if they were within scope of the project and, if so, what phase to put them in and determined if there was any effect on the timeline (changes are welcome).  Now, this is in contrast to the SDLC or waterfall model is its inflexible division of a project into separate stages, where commitments are made early on, making it difficult to react to changes in requirements as the project executes. This means that the waterfall model is likely to be unsuitable if requirements are not well understood/defined or change in the course of the project.

Success!

Our lessons learned from this process was that it was key to only have the expert users at our meetings and having more than 1 meeting a week really kept the project moving along.

Checkout the application in use!

Notable Quote

In most organizations, a stakeholder's attention span is pretty short.  Long projects that require a lot of stakeholder patience tend to falter and ultimately fail.  Providing value regularly, at short (3-4 week) intervals, keeps stakeholders engaged and interested. -@task blog

Going forward …

Determine other organizations using Agile methods who are submitting to the FDA:

http://rdn-consulting.com/blog/2007/07/22/agile-development-in-a-fda-regulated-setting/

http://www.klocwork.com/blog/2009/08/agile-2009-day-4/

http://thetestking.com/content/software-life-cycles-fda-regulated-companies

http://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm085281.htm

http://thetestking.com/content/software-life-cycles-fda-regulated-companies

http://thetestking.com/content/does-agile-software-development-mix-well-fda-regulations%C2%A0