Program or Project / Waterfall or Iterative

Posted by

a083c-4fc13-image-asset
Friends –

I’m putting together a lab for a course and I thought I’d see if anyone had some ideas for the kinds of scenarios I should include –or the aspects of the scenarios that I should highlight.

The back story is that I’m trying to help folks identify when they should be managing something as a project vs. a program.  (For instance, BPA or RPA might be a program but implementing BPA or RPA for a specific process would be a project.)  I’m also asking students to decide whether the project should use waterfall or iterative development.  (For instance, you would build a marketing web site as a waterfall project and a customer portal in an iterative way.)

With that in mind, what are the hard scenarios that you’ve come across that weren’t clear whether it should be one project or a program of projects?  What are the scenarios where you questioned whether you should do waterfall or iterative development?

——————————
Robert Bogue
President
Thor Projects LLC
——————————


12616-efe8c-image-asset

Hey Rob,

My 2 cents (maybe 3 cents since I do have a PMP, LOL!):

  • ERP should always be a programme (way too many aspects and moving parts to manage properly as a single project.
  • ECM (or Content Services to be Gartner friendly) needs to be a programme
  • RM could be a project or programme, depending on scope.  For instance, if scope is strictly physical records I would manage as a single project.  If scope was physical records, digitization/ingestion, and electronic records, I would do that as a programme of at least 3 projects.
  • EAM is almost always a programme.  Just the IM aspects can potentially be a programme before you even really get to the technology portion of the show.
  • CRM can potentially go either way depending on what business units/functions are involved.  For instance, if it is strictly for sales/business dev, I would structure that as a single project, whereas if it is for sales, marketing, and customer service (and especially service/help desk), I would absolutely break that into multiple projects in a programme.
  • Custom developed solutions gets much harder to decide, in my opinion/experience.  With that I generally look at the range of stakeholders and if the solution logically divides into some sort of modules.  If it does, and there is a significant range of stakeholders, I would likely go programme.

So, as a rule of thumb, I generally consider that if there are 3 or more business units/divisions that are primary stakeholders, and/or there is a multi-country situation, and/or the nature of the work involved has fairly distinct boundaries (such as developing IA for an ECM versus defining IG), I would encourage to manage as a programme.

Obviously, that’s not a “textbook” way to make the distinction.  Much more of a practical-tactical.  Textbook would be to manage any undertaking as a programme where you can get benefits not available when managed as a single project or where the nature, scope/scale, or sequencing of work is such that it endures for long periods of time (3+ years seems to be a fairly common barometer).

In terms of waterfall v. iterative v. Agile, I would generally look to waterfall for ERP and EAM due to the highly structured nature of both those applications and the major stakeholder business functions finance, procurement/supply chain, manufacturing, field service, etc.).  Beyond those, I generally try to encourage an iterative approach (I have a methodology I’m especially fond of: University of St. Andrews Lean Project Process).  IMO, Agile (even SAFe) is best left to custom dev, integration, or significant customization efforts.

Hopefully that is helpful?

Aria

Aria Business Card-0۸
Aria Business Card-۱۰


a083c-4fc13-image-asset

Lorne –

Yep.  It was helpful.  I tend to see the decisions as easy so trying to find things along the lines isn’t easy.  I added a few scenarios based on these ideas.

For me, both program vs. project and waterfall vs. iterative are techniques to manage the scope of complexity.  Sometimes it’s appropriate to manage things as an iterative project and other times as a program using waterfall.  It’s a judgement call — but one that I think can be taught.

As for waterfall vs. iterative vs. agile, I generally break this down into simply waterfall vs. iterative because agile is a type of iterative.  I could just as easily have RUP (Rational Unified Process) as a variant for waterfall — but I don’t believe it’s important at this level.

If people can understand where different approaches work better they can select the methodology they like most.

Thanks.

——————————
Robert Bogue
President
Thor Projects LLC
——————————


a083c-4fc13-image-asset

Like your line of thinking Lorne.

When I look at an ECM project, I conceptually divide it into components that align with a predictive project approach, an iterative approach, and those suitable for an adaptive (fully agile) method. For example, the repository structure, taxonomy components, records management, and privacy control components are better served by a predictive approach.  Business process improvements components such as workflow and case management may benefit from an iterative approach, where deliverables are chunked out in ways that provide an immediate benefit. Finally, reporting and analytics components can be adaptive, with requirements determined and modified right at the beginning of a sprint.

——————————
[Norman] [Mooradian]
[Sr. Solution Analyst]
[KMBS, Inc.]
——————————


12616-efe8c-image-asset

Great comments, Norm!

might push the business process work, particularly if it will be managed in the technology as workflow, BPA/RPA/IPA, into an agile sprint, but other than that completely agree.

Aria

Aria Business Card-0۸
Aria Business Card-۱۰


a083c-4fc13-image-asset

Agree, and should add that these divisions might start with the functional category but also depend on context of application. For example, some reporting requirements might be known in advanced and regulated (e.g., incident reports) and therefore be well served by a predictive approach. Some business processes may also require a predictive approach, for example, a disciplinary process that requires due process and procedural consistency.  Other business processes could easily benefit for a full blown agile process (e.g., customer service).

——————————
[Norman] [Mooradian]
[Sr. Solution Analyst]
[KMBS, Inc.]
——————————


a083c-4fc13-image-asset
Robert,

What about a project that requires both Waterfall and Iterative. I was working with government client whose data retention for a particular government program (pension) required retention of 50 years past a person’s life. They were interested in updating the governance and management of the data. Given that no technology is stable over that period, how would you design program/project to support the 50 requirement. My response included both a project to create / update the strategy and suggestion of a program to keep the strategy/solution relevant.

——————————
Alan Frank
Business Process Analyst
ASF Consulting
PhD, CIP, IGP
——————————


a083c-4fc13-image-asset
Alan –

For me that’s a records management program.  I see the implementation of a schedule as the implementation with the best we know now.  Another project will come in the future with the intent of migrating records from the existing system to a new system.  This isn’t any different than paper records that were converted to electronic through scanning — at least to me.

——————————
Robert Bogue
President
Thor Projects LLC
——————————

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.