Why does IT need projects?

For many years as an application development director I struggled with the balancing of large IT project initiatives against a lack of good project managers, limited desire from the users to devote that much time; and the impacts of those projects on the rest of the development team. We tried hiring more project more project managers. We tried buying expensive portfolio tools. We tried setting up a PMO.

Nothing worked. Every big IT project ended up not delivering on the desired goals and created negative impacts across the who application and broader business user base. Its easy to look at this and say well you didn't follow methodology x or best practice y or use the latest tool but I felt it went much deeper and that the era of IT projects is coming to an end.

So what is the answer?

My solution was to dissolve the PMO, remove the project managers, stop the IT projects and instead focus on delivering incremental business value through use of Agile and scrum. We started off by looking at our application portfolio and creating teams around the key applications that drove the business. These teams were mostly fixed and targeted on developing their application set. They took ownership for the roadmap for that product set working with vendors and key users to identify how this product could evolve over the next three years to better support the business.

Initially we identified product managers from IT to own these products and to lead the development of the roadmap as well as to act as scum masters to engage the team in developing agile practices to develop user stories, build the back log, prioritize, build a release plan and tie the release plan back to the product roadmap. Each of the teams came up with a definitive release plan of between 8 and 12 weeks and began to work with users to fill out the back log. We quickly came to see that there was a piece missing. There were too many users and we did not have a point of contact who could take those needs and prioritize into the growing backlog. We instituted the role a Business Relationship Manager (BRM) to act as the voice of the customer for a functional area (e.g. finance, purchasing, customer service, etc).

The BRM was tasked with working with the key people in the functional areas to build out a business roadmap and then to identify needs from the road map. After agreeing the prioritized needs with the business to bring those to the team release planning meetings to discuss how these will fit in the overall product road map. This process created some conflict and certainly a lot of discussion between the regional vs functional vs technical needs of the product teams. For the first few release cycles we had a number of misses where requirements that should have been prioritized higher were missed and others that were "gamed" to get in earlier. However, after a few peer reviews these misses started to fall away as the team got in to the cadence of the releases and planning.

It was not all honey and roses.

The biggest hurdle we continued to trip over was where large requirements hit two or more teams and we needed cross team coordination. This fell on the BRMs and made them into mini-project managers which they were not always suited to do. We also struggled with "big" requests like implementing a new solution or a product that did not fit into the model like SaaS. This mindset change of a releases date driving what was delivered vs the requirements driving the date took a lot of communication and change management that was still on gong.

So did it work?

YES!

We became a lot more responsive to our internal customers.

We became a lot more transparent in the way work was identified, approved and scheduled.

Moral in the teams rose as they were part of delivering a product and not jumping from project to project.

We had stability and visibility to the work coming in and we had a mechanism to discuss relative priorities with the key users.

We were flexible, everyone knew that it took a major business shift to change the current release but the next release was open to change up to the point we started that release so we could change as the business priorities changed.

Project management overhead went down and was spread across more people.

However. we had lots of room for improvement...

Big requests created problems. It was tough to ensure we had the request decomposed across each team and correctly prioritized. One of the next steps would have been to train and grow the BRMs with project management skills to help manage these requests.

Support activities like training, documentation, etc that are normally included in the project plan had to have user stories set up and put into the backlog and these proved harder to manage and time to releases. This proved to be a little clunky as we had it implemented and needed to be developed further.

Outliers (like SaaS) solutions did not have a natural home and we had to work at making sure these did not fall through through the cracks. A better mechanism for supporting these outliers was needed.

We used Microsoft Visual Studio Team Foundation server and this worked really well for each team but created challenges for me in reporting and visibility of the bigger requests and road map items. This was probably fixable we just never had enough time to get this better managed.

Additional information