Different PM and SDLC approaches to projects within program

I have a question hoping someone can help me with.

I am currently working with a client on a major global software program. The program has multiple sub projects, most inter-related, and with unique sub project environments. For example, one project may be regulatory driven under tight deadlines where abridged PM processes or SDLC approach (like Agile) may suit. On the flip side, this program also contains projects that have no regulatory obligation/are "nice to haves" with very lenient timeframes in which more complete and robust PM processes and SDLC methodology more suitable. (Problem does come in when these two projects, for example are inter-related, and will get to that in a second).

Up until this point, the client has insisted on using 1 PM methodolgy and SDLC methodology, irrespective of project. Obviously this has caused problems. Projects that require agility and timeliness often lag while projects that could do with more completeness are often performed quickly but with an unnecessary toll on quality or incomplete thoughts on cost. It seems to me the client would benefit from a more flexible approach to PM & SDLC as per project, as opposed to always having to utilize 1 irrespective.

I would like to suggest this to my client, but recognize many of these projects are inter-related and this could create streams of projects utilizing waterfall, for example, that are then silo'd from the projects utilizing agile. Same problem w project management methodology. For one project, we may go very robust on 5 processes, whereas for another we need to take an abridged route. Obviously as projects are inter-related, expectations could also get confusing for staff.

I'm wondering if anyone has ever dealt with the situation above and can provide best practices for the program described/what practically has worked and doesn't. Tx

admin's picture

I am not sure if you have already made a presentation to the client, but I see your point. Some projects can be done in Waterfall model and some in Agile there is no need to have a uniform methodology.

You will have to take an example of a critical project where agile fits the best and waterfall will not work , likewise take example of a nice to have project where another methodology will work .

The cons of using uniform methodology has to clearly be articulated to client and impact should be quantified in $$. For Eg. you can say "Not using Agile methodology can cost your $$$ overrrun in cost". Such analysis never fails to convince the client.

Try to understand why client is pushing for uniform methodology. Ensure that your approach accounts for the benefit client is looking for. That way its all win-win for them.