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
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.
We made a conscious decision at Solstice to not create job titles that pigeon-hole our consultants into specific areas of IT delivery. We have problem solvers. We have people who are smart and get things done. Sure we all have roles we prefer to play. 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 damn mainframe apps are still around!
Thanks for reading and as always, let me know your thoughts in the comments below.
Until next time,
J
Wednesday, July 30, 2008
Subscribe to:
Post Comments (Atom)
Posts
27 comments:
Hi Jay,
Right on target! Too much segmentation on IT roles. As an operations person on the business side, I don't understand why I know the business process management tool better than most of my IT counterparts. Mostly, because their various roles only concentrate on one specific area. We advocate smaller project groups with passionate people to deliver faster and sooner. Then we transition this working app to a larger group that will take an application corporate wide.
Thanks for writing this,
Brian Martin from your Grainger days.
Your blog just created a complete picture of what is going on in the organization where you are working right now.
But I think you have put too much blame on PM, BA or business solution architects, each have a key role and I do agree to some extent that they must know technology fundamentals to lead a project.
But in my experience I have seen excellent project managers and program managers who have absolutely no understanding of business or technology but do a wonderful job at managing the project, things like - Team building, keeping the team on track, meeting management, facilitation, communication & more communication, conflict management etc. I do not believe that just making sure that you can make a Gantt chart makes one a PM. The problem comes when a PM who internally is not a technical person and everyone knows that he cannot understand technology but he or she tries to 'ACT' as if he or she understands technology and starts talking technology. This is when management gets confused. So in your example if the PM would have said something in terms of business, management would understand, they are smarter than most of technologists.
But in your example PM was trying to be smarter by using some buzz words, but made fool of himself.
Little knowledge is indeed a dangerous thing.
Keep posting.
regards
Pavi Agrawal
Thanks Jay -
Great observation. I think the harder we define the edges of where job functions and working knowledge end, the less effective we are going to be on a collaborative Jack Welch style team. The tendency to specialize and find a comfort zone of expertise - for a PM to become a cheerleader/meeting organizer and an engineer to become a techno-functionary is something that has to be overcome both at the individual level and with a mandate from management.
Best,
Jeff
Pavi,
Thanks for your comment. Actually this isn't about any one organization, I'm a consultant so I get to see lots of different organizations, but it is a trend I'm seeing. Some teams are obviously, worse than others. I think the points you bring up about PMs are valid. Everything you mention are important leadership qualities that any PM should have. But I think there is a difference between a PM that manages a construction project and a PM that manages a technology project, and as a technology PM, you do need to take responsibility for the technology that is being developed, not just when it gets delivered.
True dat, J!
This is a problem we see often on new Agile teams and no, Agile doesn't solve the problem, but it DOES make the problem visible in about 5 days. :)
It fundamentally comes down to each team member being committed to what we call "playing to win vs. playing not to lose." This is the difference between delivering the solution that is needed, or snuggling down comfortably in the role that's on our business cards.
It doesn't require any more hours, or pain, or punishment, or an expert PM -- but it DOES require that the Team feels that it succeeds or fails as a Team, not as individuals. A good team coach (agile/Scrum or not) should strive to ensure that this Team-success ethic always holds. Cheers, --DW
I agree with what you are saying, in addition not just PM but the entire team needs to take the responsibility and accountability of the product being developed, PM for instance also has a larger share for responsibility and accountability and he can do a better job if he knows technology little bit more - be it construction or IT.
BTW, construction projects have different level of complexity than IT projects. The biggest project that industry have seen in IT is only 1.1 billion dollars spread over 9 years but we all know in construction industry 1 billion dollar project is not a very uncommon number.
regards
Pavi
Jay,
This was an excellent post. There are a few things that I see that help to perpetuate this behavior:
1. People will curl up into their defined role if the culture is such that they are penalized for trying to take ownership of activities outside their role especially if it is part of someone elses.
2. May times, as people move beyond their responsibilites and take care of things in another group, they inherit this work in perpetuity. I think this also discourages some people from moving beyond their "box" because they feel they will have more work moving forward.
3. ... and finally, SOX and the idea of "separation of duties" is over generalized and encourages people (and the overall culture) to pigeon hole people in ever closing siloed activities. This is a huge problem, as the threat of legal ramifications creates fear of having people who can do more than one thing actuallyy DO them.
I like Scott Amblers idea of the "generalizing specialist", but one can find it very hard to build those cross skills in large corporations, where the above take root.
Ron, I think you have some excellent thoughts on some of the motivations behind this behavior. It seems it falls on management to break down these walls. And probably some compliance/regulatroy specialists to really put a stake in the ground and interpret how SOX/SAS70/etc. practically applies to IT, to prevent people from hiding behind the FUD. I'd be interested in others views on this.
Good post J. I think a lot of organizations have bred this type of behavior which has proven to be detrimental to the successful implementation of many critical projects. I think one of the biggest reasons why this happens is the lack of accountability at all levels of an organization (not just the do’ers), which allows employees to claim ignorance and say “I’m not responsible” or “that’s not my role”.
In the same notion I also think that the “We needed it yesterday” mentality forces IT Managers to create teams that operate in silos and not communicate... (Even w/in the team)…rather then empower teams to have a holistic understanding of the problem, the solution and how their role is part of it. Often times simply defining roles, objectives and scope into a “pretty” document isn’t enough. Throwing more resources to a problem also breeds this behavior. What ends up happening is that you have 6 “leads” leading but no one really “doing”…and no one is clear on what they’re supposed to do. What happened to the concept of “peer training” so that entire teams are responsible for “knowing”?
I think being an IT professional or say “technologist”, shouldn’t simply mean that you understand technology or are a “computer geek”. It should mean that you are willing to take full ownership and be held accountable to solve complex technical problems from start to finish…regardless of where you fall in the organization or what your role is.
Its not hiding behind the role. You are showing a typical bleeding edge technology oriented startup syndrome who are working with a handful of people. In that setup in general everyone is a hands on coder and techie and its pretty much like a lab. There is a fundamental difference between computer Science and implementing and running business solutions. You need PM, Architect, Designer, Developer, tester, BA and also the marketing guys to understand,conceptualize,develop,implement,sale and support a business solution. Skills and jobs will be compartmentalized and thats the only large scale sustainable model. If there is a communication gap between roles its a subject flaw; IT being too young doesn't have the mature idiom of civil or electrical engineering.
All are accountable in different ways and don't think a BA or a PM can escape and the developer is the only knight in the field.
Shibaji, thank you for your comment! My post might not have been clear enough, but it's not that I don't feel there is some necessity for the division of responsibility in some cases, in fact it's necessary to scale in many organizations. My point was that if we are put into one of these roles, it doesn't give us an excuse to disregard what everyone else is doing. Ultimately, we're responsible for delivering the solution, not just our "deliverables".
"how true" this is how i felt when i went through this blog entry.PM/BSA/Architect/TechLead/Developer have no place in a project if they cannot solve the problem in front of them. They are part of a delivery model, and have to know what others are doing. Everyone have to come together to solve the project challenges. Creating a subset of the problem and solving it would not solve the problem at all.would it?
So right you are. Personally and in our team we own the projects we're assigned and make sure that we get them working, even if another department or project is breaking your work. I hate hearing the words it's not my job. Teams should own the work together an ensure that the job gets done correctly.
Thanx
I have worked on many projects where the Project Manager did not have any clue about the project. They function was:
1. Organize meetings.
2. Ask Status from Leads.
3. Prepare fancy Charts.
4. Take Everyone out for Team Dinner.
5. Approve Leaves.
If this is what is Project Management, then it did not matter if the the guy was managing a software project or toy manufacturing unit or railway lines.
The funny thing is in toy manyufacturing and railway line work, the manager would be kicked out, if s/he doesnt understand the work. But in IT, its very common to find managers who are completely clueless.
Shibaji> Did you understand what you wrote?
Jasper
What you have written about a PM in IT context, is indeed true and I am referring to a large and modern IT company based out of the US and having delivery centers in a distributed geography.
In this same company, the Architect is the one who would create all the line items making up the WBS items of a plan, and detail out dependencies. In the first place, it is the Architect who also has to create the estimates for the project effort. PM in the end was just a clerical entity, with *no* business knowledge of the project.
I was an Architect in this company and ended up doing both the technical tasks, as well as project management tasks, in terms of task completion as well as risk management. This could easily stretch my week to ~75 to 80 hours. I am glad that I do not work for this company anymore.
Another important aspect about PM in IT is that the PM should be aware of the source control management system, as well as the build system. Many a times, the PM would not understand as to why a branching needed to be done and what the impact might be to the overall effort, if it had to be merged back to the trunk. There are many other such areas where PM needs to be into, this is just an example.
Regards
Very neat Can you imagine I work with a person who has not written a single line of code for 6 years and claims to be an architect. I love my consulting job as I have to get the job done and not hold to titles.
Architect is not only focusing on software engineering or infrastructure setup or integration between systems...to me it is more towards business alignment to business objectives, how we invest in IT? how we know that every $ we spent on IT will benefit the business, enable us to meet our goals, enable us to beat the competition.
Architect not only has to understand the business, but have to know how technologies can be used to enable business go to forward, making it successful, at the right time, right cost with the right people.
Funny thing... when this ideas come from an architect they are called "trend", but when they come from a developer it is just "rant".
My experience tells me that development talent is tremendously undervaluated. In the IT world is common to see talented developers being 'promoted' to architects and suddenly a great developer is lost forever, leaving again and again (critical) development tasks to inexperienced people, situation that inevitably will lead to trouble.
Is architecture the natural evolution from development? I dont think so. Architecture and development follow different tracks and as such, they (should) have their own line of evolution
Hi Jay
"taking back ownership" is very easy to tell. But at the end of the day entire project work is put in one man head in the name of above word. It may work in water fall model but in agile with big team and small duration project it won’t work.
"but they have to own that plan" you can further explain what is not in this. I find people putting project maintenance, work allocation, status checking and maintaining quality in architect head.
Thank you for a great post! It is a subject that I have been pondering about for all of my development career. It's when people take ownership that stuff gets done! And it starts with me.
I agree, however ultimately it's the PM who should take responsibility for the project. I'm a PM, and if I don't understand something enough to explain it to the client then I'm doing a bad job. I don't need to understand all the intricacies, nor does the client need to (or often car to), however I should be able to explain that there is a technical problem that will take X days to fix. I should always be able to give X, and if I can't I should be able to explain at least when I can give a estimate. If I can't do this, then surely the client is going to ask, "what kind of cowboys am I paying here". Sound to me, it all comes back to communications, and there's no excuse for anyone not to be good (or at least try and get better) at being a good communicator.
(excuse any bad grammar :)
Cool , thats it, as a developer I have to go through every document...! Finaly the 11th hour changes !! :-) .. are realy system which we develop..
This post is good, but it's focused on behavior of team members and work of methodologists, as if they were the root of the problem. What if the problem is on the organization? There are chiefs and executives, sometimes business owners, who cannot control their business in a more practical way due to many technology changes and big company growths in recent past. They believe that processes and structures with specialized (but segregated) roles, being monitored with indicators displayed with nice graphs at executive meetings, give them control back. Unaware that this is an illusion, having listening many opportunistic lobbyists (false methodologists, that is, people without practice, but "positive" and good-looking), they sponsor such processes and structures very intensely, and put away people who try to explain 4 years before what you just have posted. As you mention, this "inevitably slows things down, increases confusion and, at the end of the day, causes projects to fail". But that's not a problem if they believe that this is under control and "would be worst without this". They don't realize that they don't have fast response time to technology issues and that they lost time to market. And with a whole industry going towards this direction, competitors will have the same problems and everybody will stay on business.
Completely agree. I think that's why so often the best project managers or business analyst we work with are those who started their career close enough to development. They just understand all technical stuff good enough to be decent partners in discussion. They have both perspectives: business (connected with current role) and technology (brought from past roles).
Unfortunately the other way around it doesn't work so well with developers. Still good developer who understands business backgroud is quite a rare gem. Actually that's a number one on my list of qualities of good developer.
Show me a successful project with all those superfluous and arbitrary project roles and I'll pick out the superhuman / herculean effort that was needed to pull it out of analysis paralysis and actually 'get the job done'.
The worst part of the whole situation is that eventually somebody (usually some poor sap developer who actually CARES about the project for some unknowable reason) gets sick of the insanity, starts cutting people out of the loop and basically 'bootstraps' the whole effort, throwing the team on their proverbial shoulders and carrying it across the finish line.
Think that guy will get the promotion? Think anybody will listen to him when he outlines the communication problems or how the role distribution was hosed? Nope. What will happen is at the project wrap up party, the PM, Architect and BA will all stand up in front, pat each other on the back and proclaim what a great 'team win' it was. And by team, they'll be rather obviously referring to themselves.
Hi,
This is a good post. I think when we think of any role either PM, Architect, BA, Developer, tester & so on, every person needs to expand beyond their "defined" role. Everyone needs to know the big picture of the project. When we have people with at least some degree of versatility, it helps for the whole team.
You might have heard this old story. A big temple building was in progress. There were various people working on the site. A person was passing by the site & was saw the work going there. As he did not know, he asked the question to a worker "What are you doing?" The worker told "I am a craftsman & as you see, I carving the stone". The visitor went to another worker and asked the same question. This worker told "we are building a big temple & I am carving the stone to build a pillar for this temple."
This story tells the difference between the approaches of people with two different mindset. Both the workers were doing the same work. While one worker was ignorant about the purpose another knew what the purpose is & what his role in the same is.
--SC
Wonderful - Hit the nail right on the head - I cannot agree more...
Of the topic: - Isn't accountability the key factor everywhere over and above IT?
Post a Comment