Projects, IT, and Transparency - how do we improve?
July 28, 2016 1:22 PM   Subscribe

We are a higher education IT operation - about 60 people - serving many internal and external stakeholders. We have significant transparency challenges internally in that there are multiple teams within IT and we often do not know what other teams are doing or working on, which can result in waste, duplication, and frustration. How do we get better?

We also have transparency challenges externally in that our stakeholders don't understand our work, nor why we are often unable to respond quickly to their immediate needs. Communication is primarily up and down the chain of directors and individuals get to pick and choose who they include in projects and communications. We have a ticketing system for issues and changes, which includes a project component which is used for managing a handful of really big high-dollar projects, but the more mundane projects are not tracked, and every department within IT (let alone outside) documents and communicates about their work differently.

Our leadership pushed us to Sharepoint thinking that would somehow solve our problem, but of course, without actual leadership, strategy and direction, it has not, and has a very poor internal reputation as a result. People still use whatever they feel like and even if everyone "used" Sharepoint, they would all use it differently. We have a tendency to buy tools thinking that they will solve our business process problems, and instead end up spreading staff more and more thinly. Our previous CIO tried to get us to adopt ITIL, but it's been only half-heartedly adopted.

Our leadership is asking staff and team leads (of which I'm one) to help them solve these challenges. I see a number of high-level needs. At least one major need in my mind is to document ALL our projects and activities (current, future and past), but we need to do it in a lightweight way without overburdening staff, i.e. make it an integral part of our work process. When I talk about these kinds of things, it can be as simple as hiring a position, or replacing a technical component or upgrading software or what some ad-hoc committee might be working on.

Personally, I'd like to ban email attachments, but no-one seems as enthusiastic about that as I am.

We need to standardize our tool usage, using fewer tools well, and standardize our documentation practices.

We have some Sharepoint-specific challenges with identity management in that our Office365 instance is our office only and not our affiliates.

Ultimately, I'm assuming we need an intranet page (project dashboard) that reveals our level of activity to all stakeholders and allows an easy dive into any project or service that is of interest.

How do others solve these challenges?
posted by idb to Computers & Internet (8 answers total) 10 users marked this as a favorite
 
This is a long question, and one that we haven't solved on our teams. I'm not in a leadership position to solve it where I am, but I'll give you my opinion on what I would do if I were in that position.

You're right that tools aren't going to solve the problem. But you're not going to solve the problem without tools. I think you need agreement across your IT units that this is a problem that needs solving. I think you need a SIMPLE template inside one of your tools for communicating product status. SharePoint is good at this, and again, it doesn't need to be fancy. You need a project lead or coordinator in each unit or team whose job it is to update that project status template. Finally, and most importantly, you need someone with authority to oversee and enforce project status actually getting done.

Treat this as an oversight activity, not as a replacement for whatever method teams already use to manage projects. Again, keeping it simple helps you because you're asking for "extra" work, and your stakeholders in general are going to care about results and not details.

You could go way down the rathole on which tools work best and so on, but I think you need to agree on the business process first and then worry about tools.
posted by cnc at 2:44 PM on July 28, 2016 [1 favorite]


you need to agree on the business process first and then worry about tools
project types
project lifecycles for each type
resource allocation
who does the work
who do they report to
what do they report

waste, duplication
assign areas of responsibility

one major need in my mind is to document ALL our projects and activities
why? compliance? budget? resource allocation? taxman? CYA? what is the useful and necessary amount of audit trail: email, memo, design notes, SOWs...for such a small org you don't need documents as much as you need insights. generally, nobody who creates productive work is better suited to reading or writing documents. generally, no senior manager will read anything end-to-end and *get* your point.

do the leads need evidence for their assertions? then document. what do you need to record for planning? then just that.
posted by j_curiouser at 3:42 PM on July 28, 2016 [1 favorite]


I'm assuming we need an intranet page (project dashboard) that reveals our level of activity to all stakeholders and allows an easy dive into any project or service that is of interest.

well, you could spin-up a sharepoint wiki in about ten minutes and begin a crowd-sourced repo of corporate knowledge. this could begin to indicate where the interest is.
posted by j_curiouser at 3:45 PM on July 28, 2016


I've done this and seen this done at a few companies. I'm not a fan of Sharepoint, but then, I'm not a fan of a lot of Microsoft tools for these sorts of things. I prefer Jira and Atlassian tools. But you're right that it's not a matter of tools; we've used tools to report on the status of things, and to give interested stakeholders a place to learn more, but that's not what made the difference.

The difference always comes when management empowers a single person with the authority to force change and approval on multiple departments. I see it as a Project and Product Management problem.

You need a single point of Project Management, someone who is able to decide on a process (iteration lengths, demo presentation style, toolsets, statuses) and able to force all departments to use consistency. But, of course, it requires the sort of person who can act autocratically but simultaneously appear conciliatory. Someone who everyone believes is acting in their shared interests, when really, it's a dictatorship.

You also need consistent Product Management, where there is a single point of accountability for how things are written down and how they are structured, and has the power to build a group of people responsible for that. But it's vitally important that that person not have absolute authority over what's done. Each individual product manager must be able to make decisions on their fiefdom without other people barging in and changing priorities constantly. The head of Product would be ultimately answerable for whether they write documentation in such a way that it correctly informs Development, Support, Implementations, Management, etc. But that head is not ultimately answerable for their decisions on what to build. If you try to make that a dictatorship, you create a major bottleneck.

Personally, if I was in your situation, I would be looking for another group that runs differently from yours, and try to standardize your documentation practices and process across your group and theirs. Use the practice to test out what can work on a smaller scale. Choose tools, create a process that fits, and make dashboards or reports that show your productivity.

If management is resistant, it's because it seems expensive to fix, and it is. It's also crucial to an organization's health, growth, and longevity. Showing them that it can be done with 1+n groups can give them evidence that if they spend money on dedicated personnel to handle these challenges, it will result in higher productivity.
posted by Pacrand at 5:02 PM on July 28, 2016 [2 favorites]


Thank you for the thoughtful responses so far. I'll try not to thread-sit, but a couple of clarifications and examples. While we are small, we support a slew of applications that hundreds of thousands of people use daily.

In terms of why document all projects and activities, one example is where another team (security) spent months evaluating dual-factor authentication products, made a recommendation and a very significant budget commitment without talking once to my team, where a number of us could have told them that we already own and pay for something that does this. Our system admin team is setting up a private cloud and hasn't asked our development people once whether it fits our direction. I don't mind these teams doing this kind of work, but without visibility into what they're doing, other teams don't have a chance to offer insight, improve things, and avoid mistakes.

The various team leads agree that this is a problem, but management doesn't have time to deal with it or recognize the pain it causes. We don't need excruciating detail, but a simple framework to help us avoid surprises.

Our PMO isn't that helpful. I worked on a major project last year and aside from doing it by the PMBOK, our project manager insisted on doing all work by email attachments so she could save it on her laptop.
posted by idb at 5:40 PM on July 28, 2016


I'm probably a bit over-eager to answer this because I worked on a similar problem at my last job and it went really well.

1. Get IT using the same processes and terminology for work categorization across their teams and platforms. Even if each of them has their own quirks and whatever methodology, at a high level they should be able to talk about work in common terms. The next step was to then start categorizing time so that a transparent breakdown of your IT resources can be provided. This is tedious without a time categorization system. We used planview (this isn't necessarily a rec. for them, just that they were used in this way). Have each IT area say who much of their group's time is allocated to your work categories. We used Break/Fix/Maintenance, Enhancement, and Project. Our two distinctions for enhancements and projects were both the time involved (e.g. more than two sprints, more than x% of a team) and the level of technology change. This allowed us to produce a roadmap with capacity data so that when we talked to the business we knew how many hours we had an when.

2. Come up with a governance and communication strategy for IT and the business to work together on project prioritization. Our gov. process was straightforward with a stage-gate review at two steps for business and IT to bring up new projects at the initiation/discovery phase. This helped IT plan ahead, vet the new systems bring brought in (this especially helped as the business kept trying to buy redundant technology capabilities). Each tech area of IT was represented at the director level (close enough to the areas to know them well but high level enough to work on big picture stuff) and they had to come to each meeting. We had similar level representation from our key business areas (HR, Finance, Legal, Customer Care, Lines of Business, etc.). The purpose of each meeting was to review the intended projects (with a two slide form) with the scope, areas needed, estimated hours, benefits, etc. discussed for each project. At the end of the meeting decisions were made whether we could move forward (to planning) for a given project. If somebody couldn't agree to go forward, there had to be a specific reason for that. At the end of each meeting a summary was sent with a link to the meeting deck (because jfc people need to move away from attachments).

3. A key part to this was selling the shit out of this to both IT and the business. This was all grassroots so I spent a lot of time on the phone and in meetings to get this going. The benefits I pitched to IT were:
-No more business bothering engineers/platform teams on their last minute project requests
-Planning ahead for major projects and aligning resources across technology
-Less time wasted deciding on priority of work -- those decisions were made for the IT teams and while their leadership had input to that, it never came down to a team lead to decide between business project A or B.
-A cohesive story for what we were doing and when it would be done

For the business group I highlighted:
-Less project delays because IT didn't know about whatever launch they decided on (I put it in a better way than that but the business groups were notorious for trying to plug in a cloud-based software and not tell the Network, ESB, or Data Warehouse people about it until almost launch and then it was a shitshow)
-Better ability to understand if their technology is a good investment
-Visibility to all projects being worked on by IT
-An answer as to the approval of their project the same day it is discussed (delays and bureaucracy were a huge concern)
-A voice on the prioritization of projects across the company

It's important to note that these were mid-sized projects. We didn't have a say in the huge/strategic projects that our executive leadership decided on but it was still a lot of hours of work being discussed at these meetings

4. Communication about the governance meetings and then the projects when they were in flight were key. I worked on project communication with the PMO to standardize what was being communication and who with. We set up distribution lists that were org based and the summary status communication stuff went out at a regular interval and was sent to pretty much everyone. The PMO was also tasked to have a common repository and method for documenting all projects they handled with a dashboard (this was another use of Planview) that gave various views to the project detail. SharePoint was our repository and there was some movement behind trying to make SharePont the dashboard tool/data thing but that was a dumb suggestion when we had a system tracking the data and I hate the idea of duplicating information.

so, in summary:
-push process and terminology consistency
-enforce using the tools at hand
-maybe invest in something to track time/hours/cost better
-get your PMO to shape up, seriously
-think about an architecture review board for the tech initiatives where people are overlapping capabilities
-if you want to hire me for this I'm pretty sure I could help
-MeMail me if you want slide decks/templates or more detail.
posted by toomanycurls at 7:14 PM on July 28, 2016 [2 favorites]


I am also in a .edu IT shop, and for years I have been talking to the line managers in other IT teams -- either informally over coffee every (other?) Thursday, or in an officially-scheduled Real Actual Outlook Meeting -- just to air out stuff like this.

Our coordination within IT has gotten better over time, but these meetings are still very fruitful. We've got a formal PM methodology that has been tweaked every couple of years, and while not every IT PM wants to follow it, the structure is good for us. I wish that groups external to IT had their own methodology, so we didn't look so process-obsessed, but we can't get by without it.

I haven't ever had our project management office involved, but since I care more about what we are doing than what we might do, it's been good.
posted by wenestvedt at 5:57 AM on July 29, 2016


(Also, there's a lot of good input above. I am out of Favorites because of the recent political convention threads -- otherwise I would have Favorited pretty much all of these. :7)
posted by wenestvedt at 5:57 AM on July 29, 2016


« Older Who did the voice over in Joe Biden's video last...   |   I just want to send you your stuff. Why is this so... Newer »
This thread is closed to new comments.