rosalyn.clarke at barclays.com
rosalyn.clarke at barclays.com
Mon Apr 7 04:06:18 CDT 2008
Hi Arthur I have worked as a (somewhat informal) PM on projects when working as a Team Lead in a small-medium sized company not big enough to employ specialists - my team did everything. I am now working for Big Banking, where IT is specialised minutely, and am surrounded by PMs of various flavours. I've been thinking about making the same leap myself. What others have said about the nature of the beast and the importance of management skills, I would support. However, I think it's worth you looking at the range of jobs available and the different kinds of companies you could work for, and the scale of the projects. It's not necessary, for example, to be a 'manager of programmers' in any direct sense. The PMs here do not generally line manage the developers. Some PMs represent the business, and some the IT side, either way their job is all about pulling together disparate bits of information and disparate people & forming a coherent plan, then trying to make sure it is delivered, generally without any direct authority over the people doing the 'work'. Negotiation, persuasion and killer organisational skills are what's needed. One way to learn more is to trawl through the job adverts and look at what experience / qualifications they ask for. In the UK it's usually Prince 2, an exercise in jargonifying and bureacratising common sense until the sense is all but squeezed out, but government and big business tend to want it. Lastly, have you thought about business analyst or solutions architect as alternatives? Both require a mixture of organisational skills, people skills and technical knowledge, but avoid the headache-inducing date-juggling and responsibility. HTH Roz -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Darryl Collins Sent: 07 April 2008 01:28 To: Access Developers discussion and problem solving Subject: Re: [AccessD] Project Management Path Arthur, Like other I can offer my thoughts based on years of hanging around corporate projects. 1: Understand that a manager manages projects. By this I mean you don't have to be a technical wizard on every aspect so long as you understand the overall big picture. Employee the folks who are the wizards and then ensure they all work together seamlessly and keep you informed on progress, budget, risks and issues. It may mean taking off your developer hat and letting the youn' uns do it their way. 2: People are usually the most complex and risky part of any project. Having one of your IT leads suddenly find out he/she is getting divorced and has lost the house and kids can really throw your schedule, budget and productivity in ways you didn't plan for. This kind of madness is can just pop up out of nowhere and you need to be prepared to deal with it. People die, have affairs, have personal issues, get arrested etc. fun fun fun. 3: You need to be a benevolent dictator. By this I mean you have to run the show and control it. You own this and the buck stops with you. Don't let the teams develop into little kingdoms that end up fighting each other, rather than moving towards the team goal - this may mean getting rid of disruptive, unhelpful or unproductive people. Make sure you have a clear goal, and a clear path to that goal. 4: Choose the best people and delegate tasks based on that choice. Again, you don't have to know everything, but make sure your IT leads keep you informed. 5: Keep lines of communication open with all stakeholders and customers. It is better to work together to solve problems that start blaming folks. 6: Have a clear objective and plan *BEFORE* you do anything. Even for seemingly trivial things this can save you a lot of grief as assumptions and other traps are often revealed when folks ask questions during these planning sessions. Be especially careful when dealing with 'fluffy' details like. "I am going to make the background a nice blue", or "Make it a modern looking site" - These statements mean different things to different folks. get samples and get consensus and then go ahead. 7: If you don't understand or know, then ask someone to explain it to you. It is far cheaper and easier to say "I don't understand that, please explain" then to get a result you were not expecting. Again, clear documentation at the start will be a definate plus with this sort of thing. 8: Be approachable. When things go wrong consider saying "How are we going to fix this", rather than "What are you going to do about it". Take ownership of the team and support them through the problems. anyway... there are probably a 1000 others, but you get the idea. Good luck and make sure you enjoy what you do. Cheers and regards Darryl. -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Arthur Fuller Sent: Saturday, 5 April 2008 6:05 AM To: Access Developers discussion and problem solving; Discussion of Hardware and Software issues Subject: [AccessD] Project Management Path At my ripe old age, I am pondering becoming a manager of software projects rather than a developer of same. I have occasionally led a team of developers toward a project goal, but more often been the principal developer of a project. I am wondering how to make the leap. While realizing that this is a list for developers, I also think that this might be the best place to ask this question. I know a lot about Access. I know a little about .NET. I know a fair amount about PHP and Python Ruby and Ruby on Rails. I know a little about some strange languages used by very few, including OCaml. I have only occasionally been team-lead in a multi-developer project. I think I did pretty well in them. So how does one go from Developer to Manager of Developers? I think that I'm growing too old to be there in the trenches of develpment, and yet that's what I love and know best. But I think that the young recent graduates have the "stay up until it works" enthusiasm that I no longer have, although that's not always true; I've recently spent 40 hours solid at the box solving a particularly difficult problem, and couldn't quit until I finally cornered the ornery pig and wrestled him down. But perhaps a younger, brighter person could have wrestled said pig down much more quickly than I, which leads to a rather sickening and embarrassing conclusion (following the Peter Principle): the best thing to do with Arthur is promote him. So, how to become a manager of programmers who are far more gifted in languages that I know a little about? How does one go from Here to There? How do I admit in my resume that I know a fair amount about the abstract language of programming but perhaps nothing at all about the language your project is using? What are the credentials of a Project Manager? I am particularly interested in asking this question here, since you are all programmers, which perhaps turns the question into "What values would you desire in your project manager?". One could trivialize this question into, "Just learn MS-Project" but that is hardly the point. Any fool can write a critical path. That's not the issue at all. As I see it (and admittedly I know nothing about the subject), there are two issues|perspectives: 1. Tell the team what needs to be done and how quickly. 2. Tell the superiors why it cannot possibly happen in said time-frame + expense-dollars. On both sides, I am guaranteed to meet resistance. Developers will say, "Impossible!" Superiors will say, "Impossible!" And the job of managing a software project is to get each team to bend a little. Of course, I know nothing about this profession, which was the whole point of this message. I'm looking for direction, courses to take, casual advice, and so on. I actually dare to presume that I could be fairly good at this profession, but perhaps not. Perhaps I'm an in-the-trenches guy not destined to coach the team. That could be. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses. No warranty is made that this material is free from computer virus or any other defect or error. Any loss/damage incurred by using this material is not the sender's responsibility. The sender's entire liability will be limited to resupplying the material. -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Bank PLC.Registered in England and Wales (registered no. 1026167). Registered Office: 1 Churchill Place, London, E14 5HP, United Kingdom. Barclays Bank PLC is authorised and regulated by the Financial Services Authority.