5

As with most reasonable sized organizations, the current organization has an operational team and a project team which drive varying degree of initiatives.

Unlike any other organization i have worked for, there is very little understanding of the deliverables each team is responsible for which has a bearing on the next initiative. For example there is a constant battle between the teams regarding ownership of documentation. When a project is initiated, there is very little by the way of understanding the current state. The project is told to bring all documentation concerning the said initiative up to scratch. This happens seldom since the project team does not see it as its responsibility to update operational documentation which should provide sufficient information about the current state.

I sit between these teams and am attempting to bridge the gap however am unsure how best to do so since there is much in the way of historical contention. Being the new kid on the block, i would like to bridge this gap. Attempting for the teams to share a common goal hasn't succeeded nor being open about specific issues and concerns. This often leads to finger pointing further deepening the already sour relationships.

Is there a specific methodology i can adopt and adapt as i imagine the situation being a common theme in a number of organizations around the globe?

EDIT

To help answer the question raised by Tobias

Role: The role i play is that of an Enterprise Architect. The key challenge i have is that there is no consistency in standards, information and knowledge is tacit and people are unwilling to share information.

The teams include project managers, business analysts, server & administration, networks & help desk. All other roles are supported by vendors.

  • Could you provide a few more details: What's your role, e.g. developer, PM? What kind of teams do exist? What is the job of the teams - development of different functions, development & QA? – Tob May 8 '15 at 19:17
  • @Tobias - I have updated my question with answers to your questions. – Motivated May 8 '15 at 19:42
2

First of all, notice that your company is (probable) successful, otherwise you wouldn't have chosen it for your new job. I'm not saying that everything is perfect but be careful being the new one telling the old ones how to do the job. My first point is:

Raise open questions. How are you doing...? What is the motivation behind...?

Maybe there is a bigger picture that causes the problems you figured out but brings a much bigger benefit somewhere else.

Fore sure, you should work on improving processes and team work. The person in charge regarding the problems within the project is the PM. Check the project plan, esp. the risk and communications management part. I assume that every project member is asked to raise risks by communicating them to the PM. Assist the PM by doing so. Say that you identified a risk within your field of responsibility and bring it down to schedule and budget. Provide a risk probability also. It should be the PMs motivation to come to the root cause of the risk, if he/she shares your view on the risk. If not, ask for explaination, you are the new one and willing to learn.

By the way having a good WBS and a working project management in place, those problems shouldn't exist (or be at least not such a big issue).

If your PM is not able or willing to work on the risk - or if he/she blames the organization processes, move on to the process improvement guys. Since you work for a larger company there will be someone (usually within QA) responsible for process improvement. The approach is quite similar to the one of approaching the PM - switch from risks to chances in your formulation.

  • Depending on the definition of success, the company performs extremely well financially. This is however in my opinion primarily because it has close to monopoly status. For example, it doesn't make sense to open another wharf since the primary incumbent fulfils the role well. I should have elaborated on the question so my apologies. There are a number of issues in addition to the lack of communication, ownership and responsibility. – Motivated May 9 '15 at 2:56
  • Since a majority of them have been there for years e.g. close to 30, introducing adaptive changes are difficult to rollout. I have had to fight tooth and nail to get some basic structures in place e.g. governance, risk and audit functions, etc. – Motivated May 9 '15 at 2:56
  • You would expect a process improvement function however one doesn't exist hence the limbo. As for a wider view, i am looking at this for an enterprise perspective. The business units do not trust the delivery arm nor the project team and hence find ways to navigate around them. I have had to sit down with key stakeholders responsible for a number of areas with the business owners so that i can facilitate communication and a common understanding. – Motivated May 9 '15 at 2:57
  • What you describe demands a new orientation of the organisation regarding processes and organisation structure. Google / look for change process and CMMI... – Tob May 9 '15 at 4:28
3

Welcome to StackExchange- Project Management.

This is not an uncommon issue in large enterprises. Clear ownership of deliverables can be a challenge. Given you're new, you probably are in a good position to do something about it, if you tread carefully. I would recommend a two phase approach.

Step 1- Conduct Stakeholder Interviews: I have used this method for several years now to great effect. My new employer uses a variation in all their consulting engagements, to equally high effect. At a high level (I should really write a blog on this): - Identify all your key stakeholders and customers. This can easily be over 20. If you hit 50, start looking for the key people in these groups. - Request 30 minutes of their time. Do this person by person, do not send out a mass email. The request should include the PPT slide and questions from below. - Create a 1 slide (just 1!) PowerPoint. The slide should have your orgs mission/vision (make it up if you have to but let your boss review it), an outline of your 90 day plan and a line with "Why am I here". - The 90 day plan should be some rif on "Listen", "Meet stakeholders and customers", "Document critical impediments", "Target Low hanging fruit", "Communicate" - Your interview questions: The secret to this method is you always ask everyone the exact same questions. I use the same six all the time. The first five are based off Manager-Tools.com Internal Customer Interviews podcast (great resource even for project managers). I'll put the questions at the bottom of the post.

The interviews work in two very powerful ways. The first is they build trust and relationships. Almost nothing is more powerful than asking people what they need and want. The second is by asking the same questions to everyone, you can create quantitative data out of the qualitative interviews.

Step 2 - Create a Responsibility Matrix You're almost certainly going to come out of the interviews with data around responsibility confusion (hint, you may want to craft a specific question to discover this like "Do you feel your roles and responsibilities are understood by the organization). Use this data and then work with your manager and the leadership of these two groups to identify this. Suggest putting together a Responsibility Matrix. I prefer the full RASCI over the RACI. Make a spreadsheet. Create columns for "Responsible, Accountable, Supportive, Consulted, Informed." Google RASCI for more on this. The two key ones are Responsible and Accountable. The person responsible does the work, in traditional development the person accountable is often higher up that person's food chain.

You're probably going to end up with holes in the matrix and places where there is conflict in who does what. From here, schedule meetings and work it out.

If you have any questions, feel free to contact me direct.

My Six Questions: 1‐ What do you and your organization need and expect from my org? 2‐ What metrics do/will you use to assess us? 3‐ How have we done relative to your needs, in the past? 4‐ What's your perception of our org in general, that perhaps the numbers don't show? 5‐ What feedback and/or guidance do you have for me/my role/my team? 6- What are your biggest pain points?

  • Thanks Joel. The biggest challenge i have even though i have attempted to have conversations is the standard in which the deliverables should be produced. For example, if it a technical design, this currently varies since most of the work is completed by different vendors and in some instances some the same vendor but different people. In all cases, there is no consistency. No one seems to know how much or how little each of these documents need to be. How would you recommend approaching this issue? – Motivated May 8 '15 at 19:37
  • I'd honestly see about putting in a Lean / Agile governance model from Portfolio down to Delivery Teams. I'm not in the habit of pimping companies I work for. That said, part of why I joined where I am now, is they have a solid model for going from Business Chaos to predictable delivery models and beyond. The heart of this is Clarity in the Backlog (Requirements) and forming dedicated, cross-functional teams the right way. You can get some idea of this from this slideshare deck: tinyurl.com/lek2cy8 (Why Agile is Failing in Large Enterprises, by Mike Cottmeyer) – Joel Bancroft-Connors May 8 '15 at 21:39
  • I don't believe the issue is so much a methodology. The issue seems to stem from lack of ownership, responsibility and basic governance. I have had to fight tooth and nail to establish some of these as well as confront a number of team members since there is a reluctance to adopt practices that deliver successful outcomes. The situation has lead to increased costs and timeframes. Attempting to put things right has increased the costs considerably since the foundation was weak to start with. – Motivated May 9 '15 at 3:00
  • Right, it's about lack of clarity, responsibility and finished work to measure against. I recommended the Lean / Agile approach as it has great success in generating these things. It's all about going to the foundation and building it first. Build stable teams and generate well understood requirements. Well understood means all the things needed to ship to the customer is understood and owned. – Joel Bancroft-Connors May 11 '15 at 14:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.