« Project Portfolio Management (PPM) Domains - Portfolio Execution
Project Implementation - Maintenance and Upgrades »

Drawbacks of Roles Segregation in IT Projects

November 26, 2008 | Author: PM Hut | Filed under: Project Management Musings

Drawbacks of Roles Segregation in IT Projects
By J Schwan

In this article, J Schwan muses on how the IT culture has changed in favor of constant roles segregation in projects, and how people, from the Project Manager to the Software Architect, hide behind their roles to avoid accountability.

I’ve noticed some changes taking place in the culture of the Information Technology industry and to be blunt, they ain’t great. It seems as IT organizations mature there is more and more segregation of roles on IT projects; and although the intention is good (and arguably, necessary) in many cases, it’s not working. The good news is, I have an idea on how we can fix it.

Let me explain what I mean by starting with an example from the past. About 30 years ago the main platform for application development was the mainframe. The structure of the teams that built these systems was relatively straightforward. There were business folks (accounting, hr, marketing, etc.) that had specific business problems, or requirements, and there were developers that built systems to solve them. The developers worked directly with the business on their issues, and were thus forced to understand the needs of the business in order to solve their problem. On the flipside, the developers also understood all aspects of the mainframe: the data structures, the code that needed to be written to process them and the constraints of the infrastructure on where code could be deployed. In other words, they knew it all, soup-to-nuts. They were clear on the business drivers , they were clear on the design and implementation work that needed to be done and most of all, (and this is where I’m going with all this) they were accountable.

With the advent of distributed systems and larger, more complex, customer-facing applications, this model became unmanageable. Technologies matured and segregated and developers started aligning themselves with specific skills, often delineated by various parts of the system (the network, the database, the infrastructure, the application server, the web content, etc.) In order to manage these complex projects, Project Management took hold to coordinate all of the tasks that were needed to build a system, and Architects emerged as the glue to hold all the technologies together. Since these guys were so busy, Business Analysts came about to act as a liaison between the business folks and the technology teams.

This is all well and good, but something important has gotten lost in the process (in many cases):

  1. Understanding of the business needs and drivers
  2. Understanding of the business system as a whole
  3. and behind door number 3 . . . Accountability

Let me give you an example. Tell me if you’ve heard this one before:


Bob the Business Stakeholder: “The XYZ marketing system project is running late and over budget, what’s the deal?”
Pam the Project Manager (looks at project plan): “The build out of the MQ platform is on the critical path and it is taking longer than expected.”
Bob the Business Stakeholder: “What’s MQ?”
Pam the PM: “I don’t really know, I think it’s a messaging platform.”
Bob the Business Stakeholder: “What’s a messaging platform?”
Pam the PM (with a slight smile): “I don’t know. See, I don’t understand all this technology stuff. I’m a project manager. Let’s ask the architect.”
Bob the Business Stakeholder: “Art what’s a messaging platform.”
Art the Architect: “It’s a system that allows one application to send and receive data from another application”
Bob the Business Stakeholder: “Why is it taking so long?”
Art the Architect: “Define ‘long’? It will get done when we get it finished, we’re moving as fast as we can. I don’t look at the project plan. I just get my work done. I’m an architect, not a fortune teller.”
Bob the Business Stakeholder: “What system do we need to get data from.”
Art the Architect: “The CRM system. We need to pull customer address data from that system.”
Bob the Business Stakeholder: “But that’s just a tidbit of info we have on one screen, it’s not even that important.”
Art the Architect: “Hey it was in the requirements document. Talk to Benny the Business Analyst”
Bob the Business Stakeholder: “Wait but. . .”
Benny the BA (pokes his head through the meeting room door): “You told me you wanted it so I wrote it in the use case. You signed it!”

They all break into laughter and hilarity ensues.

This might be a bit of an exaggeration, but hopefully you get my point. There’s a trend emerging of people hiding behind roles on a project, which inevitably slows things down, increases confusion and, at the end of the day, causes projects to fail. I received an email today from one of my favorite clients who eloquently described the problem as “Right now, we have too many silos and the interfaces between the silos are chasms.” There are several answers out there on how to solve these problems with methodologies and governance, but the real answer is simple. . .taking back ownership.

In many cases these roles are all necessary, that’s reality, but in order for a project to succeed we need to stop hiding behind our roles and get back to the fundamental understanding that we are technologists. This means that regardless of the role that we are playing, it is our responsibility to understand the business problem, understand the system as a whole and understand the plan that’s in place to solve that business problem.

This means that project managers (and BAs) can’t claim ignorance on technology problems or issues. At a minimum they should have a fundamental understanding of a distributed system, it’s many pieces and what they are responsible for. If you want a brief primer, check out my last blog entry on the Distributed Application Stack. This does not mean they have to learn to code in Java or know how to write a .NET WSDL signature. It means they have to understand core architectural fundamentals so they can speak to them intelligently and understand the context of problems that may be occurring on a project. It means that they don’t have to know the answers, but they have to know how to ask the right questions (heck, that’s the best way to learn!) It means they have to be accountable for the technology that’s being developed.

Architects (and developers) also have a responsibility. They can’t hide behind the application frameworks or data models or network topologies they so genuinely love to design and build. They have to ingest that project plan the same way they ingest Digg.com posts. They don’t have to manage the plan, but they have to own that plan. They have to understand the time and budget and business scope priorities so they can make the right architectural decisions for the problem at hand with the constraints they are given. It means they have to be accountable for not just the architecture, but the business problem, the timeline and the budget of that project.

Now there are methodologists that will claim that the Agile Methodology, or iterative RUP or checkpoints in an SDLC fixes everything. Or IT Governance or ITIL gurus who will claim a clearly defined process and metrics and monitoring strategies will ensure that projects in trouble are spotted early, just in time to allow more PMs, BAs and Archs to sweep in to save them. And maybe some of this stuff will help. But I’ll tell you what it comes down to: people taking ownership. Ownership of a project and ownership of their careers. People who stop hiding behind a role title or a responsibility matrix or a job description. People who are masters of some things but have a passion for understanding all aspects of IT Delivery. People who care.

I love technology architecture work, and if I’m working on a project that’s going to require more than a handful of people, I’ll bring in one of our PM gurus, because frankly, I’m not that great of a project manager. But I do know the difference between a Gant Chart and a Sprint Queue, and when it makes more sense to use one versus the other to manage a project. And I like the fact that our PMs understand the difference between a web server and an application server, and that our BA gurus have no qualms about doing QA work or rolling up there sleeves to fix some simple bugs if that’s what the project needs.

We’re all technologists, and I think that’s what the IT culture needs to get back to. Heck, there’s a reason those mainframe apps are still around!

J Schwan is an accomplished technology strategist and solutions architect with over a decade of experience helping define and deliver mission-critical initiatives for world-renowned companies and brands including Hallmark Cards, WW Grainger and The Northern Trust Company.

J is respected by both business and technology leaders for his ability to address and maintain equal focus on business and technology objectives and has superb skills as a liaison between business and technical teams. He is an expert in analyzing and incorporating emerging technologies.

In addition to consulting, J has written and instructed courses and workshops for the Fortune 500 and various universities. He has served as a guest speaker on emerging technology topics at many educational institutions, technology conferences and focus groups.

J received his bachelors in Engineering from the University of Illinois at Urbana-Champaign and began his career at Accenture. J is the founder and Managing Partner at Solstice Consulting, a Chicago-based technology management consulting firm focused on helping companies use technology to deliver their business objectives.

About Solstice Consulting

Solstice Consulting is a Chicago-based technology management consulting firm. Companies hire us to analyze, architect and deliver change through agile technical execution in business analysis, technology architecture, project delivery management and change management.

We deliver high impact change faster, cheaper and better than your company can do themselves. Unlike bloated technology consulting firms, we believe the best way to help our clients get from A to B is by using small, objective teams of smart, agile and passionate people who love hands-on problem solving.

www.solstice-consulting.com

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Wednesday, November 26th, 2008 and is filed under Project Management Musings. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories