Sorry, we don’t need Pure Project Managers
This was the response a friend received from a respected MNC. Before you think that this organization needs people who have “impure thoughts”, let me put it on context.
The opening was for a Project Manager to lead projects in building large E-learning courses and associated Learning Management systems. However, as my friend discovered, they needed people who had a background in Instructional Design and/or professional teaching experience! This sort of thing is sort of understandable in high-tech domains, but is becoming more widespread in web-based projects too.
This leads me to think that Project Management as a profession is in danger in the near future – either be tech-savvy enough to write a few lines of code for the project when falling behind or know the business enough to converse with the Business Analyst.
[Reminded me of the scene in the movie "Defiance" - when one of the newcomers to the camp early on is asked what he does, he replies "I am an intellectual". People look at him incredulously!]
What do you think? Can someone be just a Project Manager – someone who can handle an ERP project one day and a telecom project the next?
Business and IT: There is still a Wall!
Today has been a good “thinking” day for me so far. First, I read a great post by Peter Kratzman on Mending Wall: Matches and Mismatches in IT stakeholder expectations
Then I got to watch this great interview of Gartner’s Daryl Plummer on Youtube
While I agree and understand Business’ frustration with IT, there are a few things that make IT behave the way it does. It cannot be a coincidence that most IT shops behave this way, right?
Some thoughts:
- Do Less with More – Supporting the same or increasing number of applications with less personnel, less money, outsourcing headaches, at a time when costs are going up is forcing IT to think about survival and not about innovation! If you are firefighting everyday, where is the time to think long-term?
- Technology Innovation and Adoption cycles don’t match – While new mobile platforms can come up quickly, supporting them in the Enterprise is a nightmare with untried devices
- Security Risks are discounted – with the qualification that the discount is valid till a breach occurs. For example, giving mobile support to Enterprise applications seems the way to go, but supporting Blackberry, iPhone and Android phones increases security risks manifold. There is very less experience out there on how to do it safely. Social Media, Cloud Computing/SaaS, Data Storage are some other examples where security breaches can cost the company dearly
- Business still does not want to “own” decisions concerning IT. Moving to the cloud vs staying in-house is not IT’s sole responsibility. After all, if IT systems are down, the Enterprise is down!. In short, Business must move away from the “Get IT done somehow and don’t tell me about it” (pun intended!) mindset
- Like Business, IT has some processes and while they can be flexible, there are some constraints. Everyone has to live with constraints these days, so why be unreasonable only towards IT?
- Finally, the most important thing (at least, it seems that way to me) – the thinking that IT is a magical system that can bend however needed while Business processes are fixed in stone must be changed. I am reminded of my teacher in school, who admonished me – It can be done as long as the doer is someone else. When you have to do something, you get all the problems in the world!
So, who will bell the cat? (That’s just a saying, don’t take it literally folks)
IT. We must do a better job at communicating these to the Business. Much has been said about how to align IT with Business, but how should this alignment happen? Some case studies are listed here.
- Houghton Mifflin Harcourt’s CIO does a good job of Governance in this CIO.com article
- This CIO’s team congregates to discuss every business project that has an IT component (I like that) – Read here
- This paper from SAP America discusses the challenges and offers some solutions (Needs free registration) – Link here
I wrote some shorter posts on this here and here last year, but this seems to be a perennial subject.
Do you have other things in defense of IT? Or are you, perhaps, from the Business? Me, you ask? I believe in this quote (I have quoted this earlier too on this blog):
None of you are in IT; all of you are in business.
-Andy Kyte, vice president and Gartner fellow
The Model does not matter: Projects and JKD
Again let me remind you Jeet Kune Do is just a name used, a boat to get one across, and once across it is to be discarded and not to be carried on one’s back
- Bruce Lee, while describing Jeet Kune Do (JKD)
Over the last couple of months, I have been reading a large number of blogs, discussions, arguments, between purists on either side of the “Process fence” as well as middle-of-the-road liberals on what development model is best suited.
There are thousands of successful projects delivered using Agile, CMMI, SPICE, RUP and the hybrids in between, so clearly there is no single silver bullet. That begs the question, is there a single best way to develop software? Increasingly, I feel the answer is No. Even if you decide to go one way due to the needs of the project, it is not necessary to abide by a rigid set of rules prescribed in general by experts in that model.
How then do you decide how to develop software? The answer may lie in adapting JKD’s “The Way of the intercepting fist” philosophy, which, I believe, is closely aligned to Lean “thinking.”
Some thoughts:
- Start with understanding the nature of the project, the clients, the project teams and management needs
- Let this understanding drive the selection of the overall framework. For instance, if the project is to develop against an evolving standard, one of the Agile methods may be suitable. But if the team is not mature in terms of development practices, one of the iterative-but-process-oriented methods like the 2I or RUP may be better
- For engineering practices, use concepts and tools proven within the organization
- For project management, the established way within the organization or PMI’s methodology would be a good start
- Don’t be afraid in discarding practices if they are not useful, but be sure to substitute them with more useful ones. The easiest example I could think of is integration. A big-bang integration is not the norm these days, even in most process-oriented shops, but you can institute multiple daily builds instead of weekly or monthly ones. Another example is using Failure Modes Analysis (FMEA) to drive design decisions in iterations to prevent too much refactoring
There must be a term in psychology to describe this behavior: the moment we associate ourselves with something, we start believing that we must adhere to it 10o%, else the skies will fall on our heads!
As project managers, we must be careful not to fall into this trap, but carry a “toolbox” of practices which can be used in different situations. I am told that successful managers have this toolbox subconsciously, but are unable to spell it out exactly.
What about you? Do you think it is advisable to go with a single system of tried-and-trusted practices or have an assorted toolbox?
3 Ways Your Process Improvement Initiatives Can Go Wrong
Your Process Improvement initiative or even a simple process definition has failed. You have taken the necessary steps to see that you are not defining a stupid process and provided guidance on how to define processes. It still failed, sob. Once you have gotten over it, read on.
The 3 most common ways you can fail at Process improvement, that I have personally seen are:
1. Blind Adherence to Frameworks
Process frameworks such as CMMI or SPICE are intended as guiding principles to help
you develop processes that, in turn, help you achieve your business goals. Trying to incorporate each and every aspect of a framework without regards to its applicability in your organization can result in bloated processes that no one can or will follow.
Usually, process improvement begins with Gap Analysis of existing processes against the chosen Process Framework. This is where you can take a wrong turn.
Understand the intent behind the Framework when performing the Gap Analysis. One tried-and-trusted practice is to extract the objectives from the process (in CMMI, these are neatly defined in the Specific Goals) and then use them to see if the goals are met by your current processes.
2. Committees
Yes, Practitioner-led process improvement is the way to go. But that doesn’t mean that you try to get “representation from every section” of people into your process definition team! After a certain threshold, an increase in the number of people is only going to hold you back.
From my experience, the magic range is 3-5, but that may vary if you are in a business process improvement scenario. One symptom of a dysfunctional large team is endless bickering over every word and its intent when drafting the process – in one case, there was a 2-hour discussion on using “measurements” vs “Metrics”!
3. Endless Alternates
This can be a standalone issue or an offshoot of the first two. I have seen teams debate over different scenarios which they might face, when the probability of these scenarios occurring is really small! Usually, there are a few critical paths where the teams might need direction and then there is a catch-all section (which is usually an escalation path for more guidance).
This situation arises when
- People don’t trust themselves and others to do the right thing and/or
- Managers are not very forgiving when their teams take decisions using judgement and then mistakes happen. Only a learning environment is a growing environment and without it, you cannot help people become mature. Without mature people, you cannot have a high-maturity organization!
Yes, there are more ways in which you may fail, but I’ll follow my own advice and stop from listing out all other scenarios 
. That, however, does not prevent you from adding your own experiences in the comments. They may be a bigger cause of failure!
Do share in your experiences in process improvement and of course, subscribe to the blog.
Lean, Kanban and Agile – An interview on MSDN Radio
This blog is usually a mouthpiece for my ramblings, but sometimes it is good to simply listen to others. I found out that MSDN had a radio channel and considering that Kanban is the new black, this is a good interview of 3 lean/kanban guys. Exciting folks to follow!
[If you cannot see the audio player below, you can listen to the audio-only interview at MSDN Radio Special - Kanban Lean or Mean][cincopa A8GAOaad7gMc]
