Discussion

By Joseph Pasky on Nov 29, 2017

Realities of the Project Schedule: "The first 95% of a project takes 95% of the time; the remaining 5% of the project takes the other 95% of the time"

By Brian Shipe on Nov 29, 2017

Jennifer,
Thank you very much for this post. I can whole heartily vouch for the approach of Agile (with Jira) in software development projects. Scratching my head a bit on how to Port that workflow into an MIS implementation. Do you use User Stories to the same degree in Software Dev as you would with an MIS project?

Before Agile, what were the Project Management process methodologies that were being used by the "ineffective" Project Managers you dealt with?

Does Agile significantly increase the estimated Project Management Hours you'd expect? Are those hours usually tied to estimated implementation hours - say 15-25% of the overall project estimate?

By Jennifer Matt on Nov 29, 2017

Brian,

What is Agile? It is a project methodology that is based on the fact that YOU DON'T KNOW HOW THIS PROJECT IS GOING TO GO FROM START TO FINISH.

I think this is the #1 problem with "traditional" project management. We sit in a conference room and guess what the tasks are, how long they should take, and then come up with a date based on pure delusion. (probably a bit of an overstatement but you get the idea).

What project is 100% defined from the start?
What project does not change once you get into the project?
What project have you been on where tasks can be precisely defined as far as effort and calendar time?

Agile is about breaking the project down into smaller "projects" (Sprints), then having formal adjustments (aka prioritization) after each Sprint.

How could that apply to Print MIS implementations?

There is so much room for improvement with MIS implementations, I'm not sure where to start. Lets just start with keeping leadership involved. Invite them to review the list of tasks (you can use tasks instead of stories(but the tasks should be written in a manner that the BUSINESS can understand). You do not accept the "too technical" for business to understand excuse. If you can't explain it to the business, they they should NOT be paying for it!

For example:

Review the customer list for accuracy in current MIS or accounting system before import into new MIS so that ONLY active customers are being imported. This is a task written in a way that everyone can understand.

This story/task probably has several sub-tasks to it b/c there isn't usually a single person who knows about every customer.

Small projects have a better chance of getting completed on-time, on-budget. When you are forced to prioritize multiple times during a larger project b/c you've broken it into smaller projects/Sprints - you greatly lessen your chances of going off the rails for months at a time. With every smaller project completion, the team gets smarter about the project. They get better at estimating tasks, they get better at determining what is the next most important thing to do.

Too many Print MIS implementations go on for months and months with the business owner in the dark. Partly b/c the are not engaged and partly b/c the vendor has not put in a process that is worthy of their engagement. Most print business owners I know went to one worthless project meeting and then stopped paying attention b/c it was not well directed, did not have a centralized place where all updates were being managed, and was therefore nearly impossible to engage unless you had been in on every conversation and email.

Projects are about getting stuff done with multiple people, over a period of time. They fail due to role confusion (e.g. I though the vendor was doing that!, and goal confusion (e.g. I didn't want the standard Print MIS implementation, I wanted one that works for our business!).

By Jennifer Matt on Nov 29, 2017

Joseph,

I don't think we know enough at the beginning of projects to be 100% sure of anything. I think we need to constantly be re-assessing our priorities. In many projects I've been involved with over the last few years, I've heard myself say "why are we doing this task?"

When we are overconfident in the beginning and then insist on following through on the items we defined in the beginning we risk the ultimate failure - delivering on a project that fails to meet the business need! Lots of effort, lots of money, no ROI. It drives project managers crazy when I do this but I like to ask why, even on things we've already decided to do. Our job is to ONLY do what's really important. You don't get any brownie points for volume of tasks - the only score that means anything is "did you do the tasks that are important/required for the ROI?"