Well, it’s been a while since I’ve discussed process
issues. Time to dig in and have some
fun!
Most of you that have followed my previous posts know that I’m
a process kind of guy! I’ve introduced
formal lifecycle management into several organizations. The teams that I’ve led have successfully
utilized process enhancements to drive improvements in productivity, overall
capacity and quality within various organizations large and small. Utilization of a known process allows you to
begin to measure various pieces of the lifecycle – looking for inefficiencies
and issues that impact your overall ability to deliver for the organization.
Now all that said, each organization needs to find the
lifecycle process and development paradigm that will work with their
culture. I’m not going to try and tell
you what development paradigm you need to follow because I don’t know your
organization. Within the organization I
currently work for we largely follow a waterfall process with some agile
techniques utilized within various teams.
This works for us and the style of applications that we create/support –
mostly technical interfaces within the payments industry. Our overall lifecycle has various
checkpoints/gating that we use to validate we are ready to move to the next
stage. This works for us! We’ve significantly increased our
productivity and capacity over the last decade and have improved the overall
quality of applications that we are delivering to our production environment.
While all this has been good, I occasionally notice when
people are hiding behind the process versus just getting the work done! Not every project needs every step of the
lifecycle. Some are small enough and
straight forward enough that we can skip various parts of the process or make
the decision not to create some of the standard artifacts/documentation.
Decisions need to be made up front when the project is
defined. Those in the know, need to
direct the teams when a project needs the full pomp and circumstance of the
lifecycle and when the teams have the option to skinny up the process and skip
parts of the lifecycle. That means at
the very earliest stages of Discovery, the Project Sponsor should be giving
direction to the team on what the risks are associated with the project which
can then drive decisions on how much of the process can or should be used on
the project.
Additionally, once a project has been initiated, I think
individual team members need to be cognizant of what is happening and make
recommendations to the Project Manager if they feel certain pieces of the
lifecycle could be skipped or maybe some documentation might not need to be
created. I’m not saying that we’ll
always make the choice to skip over pieces of the lifecycle or to not create
various pieces of documentation, but as leaders, we need to listen to the recommendations
of the people closest to the work and if it makes sense, say yes! When we decide that we can skinny up the process
used within an individual project or that we can eliminate some of the standard
documentation, those decisions should be documented. That way, there is a record of the decision
and the reason is documented and shared with the Project Sponsor.
Overall, we still need to deliver for the organization! Delivering the requested solutions with the
necessary features/functionality; delivering a solution at or below the expected
budget; delivering a solution with the highest levels of quality. Our teams should be held accountable to
ensure we are delivering successful solutions at the end of the project.
If you'd like more information on my background: LinkedIn Profile
