Exploring trends and developments
in project management today.
Must Project Managers Be Technically Savvy?
Must project managers be technically savvy? This topic always seems to cause quite a stir. While some believe that all you need to manage a project is a PMP certification, others are convinced that you can't successfully manage a software development project unless you truly understand the intricacies of the product.
I agree! To be an effective project manager, you must know the ins and outs of your solution. You must be capable of designing and developing the solution yourself.
Here are 5 fundamental project management tasks that project managers can't accomplish unless they have a strong technical background and truly understand the particulars of their product.
Estimating Effort
In order to create a project plan, you must be able to estimate how much effort is required to complete all of the required tasks. Needless to say, you can't estimate effort unless you truly understand what's involved in designing and implementing those features.
Unless you understand what's required to reach 5-9 reliability, you can't assess how much effort is required to achieve this non-functional requirement. Unless you clearly understand how to write Java Server Pages, you can't predict how much development effort is required to transform an HTML prototype to set of fully functional JSP pages.
Scheduling Tasks
Imagine that someone hands you a list of activities that need to be completed for a given project, along with the overall effort. Could you schedule the tasks in a logical sequence? Should the developers start with the presentation, the business, or the data storage layer? Which comes first when working on a presentation layer: the HTML, the JavaScript, the CSS, or the servlets?
A project manager must be able to schedule activities in a logical sequence. If you can't determine which activities must come first and which ones can be done in parallel, you can't put together a project schedule.
Assessing Risk
Imagine the following scenario. Your product is scheduled to be released in 5 days. The QA team discovers a defect in the API through a series of CLI tests. After carefully examining the problem, you realise that you're developers have been working around this defect for months.
Given that you're only 5 days away from releasing your product, should you fix this defect or document the workaround? At this point in time, how risky is it to modify an API that's being used? How confident are you that the developer can fix this API in the given timeframe? What's the likelihood that changing this API will break the modules calling it? Should you fix the defect now, or release the product and address the bug in a patch release?
Unless you've seen the code behind this interface, you can't answer any of these questions yourself. You need to ask your developers. You're not the decision maker. They are.
Participating In Customer Meetings
Customer meetings always end up in technical discussions. Unfortunately, if you can't speak intelligently about your technology, you can't add any value to such meetings. You're not participating; you're strictly listening, and perhaps taking notes. Sooner or later, your customers will find themselves contacting your developers directly. "Why contact the project manager if he can't give me an answer? I may as well go straight to the source."
Ensuring Nothing Falls Through The Cracks
Let's face it. You never get as much time as you'd like to plan your projects. What's important is not that you get it perfect the first time around. What's important is that you can catch the tasks that fell through the cracks before it's too late.
If you don't know what's required to complete your solution, you won't be able to identify all the overlooked activities. They'll either be pointed out by your developers, or simply omitted forever.
In Short...
To be an effective project manager, you must be capable of designing and developing the solution yourself. Otherwise, you have two options. You can either (a) ask others to make decisions for you, or (b) simply pretend you know what you're talking about. In the first case, you're a project co-ordinator. In the second case, you're a project mangler.
Luc Richard holds an MBA with a major in high technology. For the past 10 years, he's been managing the development of software applications.
Related Articles
Eight Easy Steps to Managing Your Website Development
Managing your website development need not cause you sleepless nights providing you learn the secrets of successful project management. Perform the best practices in project management and give your project the best chance of success.
Managing IT Projects: Theory or Practice?
What is the best approach for successfully managing IT projects, knowing the theory or applying your experience? This article aims to provide some answers and suggest the best way forward to ensure a successful outcome for your future projects.
9 Steps to a Hassle Free and Effective Software Development Project
Has your company developed entirely new software or added to software already in use throughout the organisation and found the process cumbersome, frustrating, and sometimes not living up to expectations or meeting organisational goals? If so, the solution to a smooth and effective development programme may be as easy as staffing a well-qualified project manager and adopting a proven development process.
Six Rules for Great IT Project Success
Between cost overruns, project delays, unfulfilled expectations and quality control issues, less 30% of IT projects are successful. This is unfortunate because, conducted and delivered well, projects are one of the most powerful ways IT contributes to a company's bottom-line. Use these six rules to get your project back on track today.
21 Ways to Excel at Project Management
The popular project management eBook now fully updated and available as a website for the first time.
Sounds like an problem with teamwork/delegation/communication. Everyone has their specialities, including the PM.
"In order to create a project plan, you must be able to estimate how much effort is required to complete all of the required tasks."
But if this were true, the PM would also need to be an experienced tester, documenter, business analyst, contract negotiator, architect, trainer, etc, etc.
Why should the PM be satisfied with techno-babble? there's the weakness - responding with "duh-OK!"
Many people may argue against this perspective and that is fine, however, on the ground, companies across the industry board are increasingly demanding that their PM's are technically competent and this is especially true for IT. Just look at the PM job adverts to verify this trend.
Imagine a supplier in say a refurbishment project saying to the project manager, "the project is going to be delayed for six weeks due to excessive saponification on the outer walls due to effervescence of the alkali salts carried through the building material by the evaporation of water penetration; and it will also cost an extra 6k to install a bituminous fibre damp proof course" etc, etc.
Don't you think the customer who has absolutely no idea of the building trade and who has hired the PM to run the project and look after their interest, would want the PM to be able to question the supplier and if necessary to make alternative suggestions. At the very least s/he should be able to verify that the extra work is necessary and warrants the additional expenditure.
Management is the art of obtaining results through other people’s efforts. The PM debate is centred on whether you lead intelligently and proactively from the front or through ignorance, retrospectively from the rear; it’s really all about balance and harmony among the team.
As a production manager I always asked my employees how they liked to be managed. I had one staunch old-fashioned union guy who said quite bluntly show me what to do then f*** off and leave me alone. Fine I said, ‘I will teach you what you need to know and then leave you alone to get on with it’, ‘but I want something from you in return’, he snorted ‘what’. I said, ‘I want you to immediately call me if you get into any trouble with your production’. He said, ‘fine’, and he turned out to be one of my best operatives with top numbers and least rejects.
Source: "Agile Project Management", Jim Highsmith, Addison-Wesley, Second Edition
But that would defeat the purpose of working on a team, wouldn't it? In my opinion, a project manager should have a solid understanding of approaches across all disciplines. There is no need to have a practitioner-level understanding, because that is what the practitioners are there for. Project managers are meant to understand the work effort, scope and timeline, and communicate project details with a level of knowledge that keeps clients informed.
If you're a project manager and you think you can do the job better than the person assigned to a role on your team, you probably have issues.
In all cases, technical knowledge is a weapon that a manager needs to be smart enough to know when to well utilise ... just what I think of
A PM should be very (really) strong in the process SDLC, PM processes, and other sub processes (defect, change, risk, issue, SCM, etc..) Project Management is a art by itself, I have seen many tech savvy people taking up project management and (most) ending up being a failure. The art of project management is learned over a period of time.
Learn Professional Project Management by unlearning your view of project management. Hiring Dev, QA, BA, SCM, Tech Writing, Training etc.. Its a huge list of team members you will be interacting with on a daily basis. As a PM you will not have time to get into technical details of the project. Think big, let the specialist do the job. Yes you do interact with business, but on a different level, only in small companies do you see PM's discussing technical requirements with clients, its not PM's business, its an architects work. As a PM you should work on deliverables, billing, reporting milestones, change management. Don't let your focus loose on getting into technical details.
PM's should have very powerful communication. He should be able to escalate and delegate work as and when it is required. Set up communication expectations. Don't let the project deviate from its scope. As a PM understand the high level requirements of the project. Create a working atmosphere where the team is free to execute a project. That doesn't mean that a newbie can be made as a project manager. My point here is you don't have to be technically savvy to take up the post of a PM. But you need the experience to handle pressure. You need to be respected.
Be smart, active and keep you eyes open and know what is happening all across the project, not poking your nose in design, requirements, cutting estimates just to show that you have been a developer born PM. Instead why don't you create checkpoints, exit criteria and define a process around it.
Richards article works well for newbie companies, but remember that will not be applicable in any of the big projects for any of the points that he has mentioned above. My point here is not defending a technical guy from becoming a project manager. The point here is a PM doesn't need to be a Techno Savvy. I have seen lots of Management Graduates who take this post as a challenge and execute better than a techno savvy PM. This is just a 50000 feet overview of it.
Also I fail to see how a PM could encompass the level of technical knowledge required in order to deliver a multi skilled technology project, are we to believe that the only way to successfully delivery a project is to have a PM technically adept in Network programming, OS, Java, C#, vendor proprietary code? Impossible, I know of no one within IT who is able to deliver a multi faceted IT project alone. I regularly deliver CTI project that encompass a myriad technologies and have yet to find a consultant or engineer able to cover all areas with a technical proficiency that would be required for delivery.
Also a key aspects to the PM's role is to question the requirements analysis and tech design, to ascertain that the design meets the requirements, to ask the questions from a business angle, so we don't end up with a technically brilliant solution that no one can use.
Maybe if the project is only centred on a single application using a standard technology, with limited external interfaces, I could agree but in the current climate of clients moving towards full scale application integration this is a very old and somewhat impossible aim.