By Andreas Maratheftis on Thursday, 5 of June , 2008 at 7:10 am
There are a lot of reasons that can determine the success of an IT project; one of them is the project manager. A good project manager can salvage a loosing situation and make the project a success. I wouldn’t call the list below as strict do’s and don’ts, (some are however-logical), but rather some advise, from my experience.
The Do’s
- Make sure you provide the client with up to date information on the project status and progress
- Involve the client all phases of the project, especially in prioritising task and business requirements.
- Ensure you understand the business and the users and manage their expectations
- Keep to a scope and use techniques to manage scope creep and changing requirements.
- Provide constant feedback to the client but also request and demand feedback on items build for the client.
- Keep the upper hand on your backlog.Enforce procedures that both complete changes/bugs but also move the project forward.If you have a team of five, two can cover changes/bugs, two can build new requirements and one can be testing. These roles can change regularly to break routine but also to keep each member involved with items throughout the project.
- Enforce collaboration between developers, and managers and between end users.
- Enforce a process. Everything has a process underneath it’s just a logical way of doing things. e.g all bugs must be logged through an online bug management system etc etc.
- Not too much documentation. It really depends on the Project, perhaps a better way of putting it is no unnecessary documentation.
- Plan for risk and always incorporate it in your project plans.
- Estimates from developers are not always dead accurate. Question them if you have doubts.
- Always say the truth no matter what the reason.
- Deliver quality. Meet the deadline with an 80% fully working product than 100% with bugs and loads of issues.
- Check your costs and resources. Although the above point is valid, make sure your projects are delivered to budget.
- Get your hand’s dirty.If you know some SQL,some Programming? Use it.Do some testing and be a part of the team,in the team not an outsider.
The Don’ts
- Do not ever ever ever lie. Once,twice three times you will get away with it, the client will catch up with you at some point and you will not be trusted.Say the truth,it’s better than lying and it always pays off in the end.It also helps to manage the client’s expectations.It’s better to say “i will deliver 60% of the requirements by September” than saying 100% and not achieving it.
- Don’t criticize and judge others all the time.Some is necessary but there is always a limit.
- Don’t make promises you can’t keep. It’s more practical do say that a request will be reviewed and delivering those in stages rather than saying yes to everything and doing nothing.
- Do not badmouth or talk about your client behind his back.
- Don’t be lazy, when there’s will there’s a way.Problems can be solved,just be persistent and consistent to what you do.
- Don’t be an idiot.Screaming and shouting does not solve problems.Delegate and find the balance.
- Do not cheat your clients. Some times you can’t charge for everything.
- Do not put the blame on others. If it was something that you were responsible for,take the responsibility and learn from your mistake.
- Escape from the process. And when i am saying “process” i don’t mean a straight line, everything has a processes whether it is user collaboration, agile methods or structured/traditional.
As you can see there are many things that makes good project managers differentiate themselves from “project managers”. You just have to love what you do and try and be the best at it even if others or the situation does not help,give it your best and it will be appreciated. Add more or provide links in the comment’s related to this post.
Category: Business, People, Project Management
By Andreas Maratheftis on Wednesday, 28 of May , 2008 at 6:21 am
Or even Business analyst’s? Maybe i should put the question differently. Are you a better Project Manager or Business Analyst if you started off as a programmer?
I had this debate with a lot of people, especially when i went to a couple of interviews here in Cyprus when i was looking for a position. My personal answer , i am not sure. I can understand the difference on both occasions.
Firstly if you did let’s say 5 years worth of solid programming in the industry and have been involved with a good number of IT projects, naturally the next step-up would be a team lead/technical lead/PM type position? And i can see the benefit, you can better understand how things work if you’ve done it yourself. You would be able to better plan a project and have the technical know how of how things work, what did go wrong and be able to prevent bad issues that you’ve dealt with as a developer from affecting your own projects. On the other side of things however, as a programmer however your are missing the involvement with clients, the business accument, the delegation and understanding off the outer workings in a project, the soft skills and seeing the big picture and managing from above. (not everyone of course)
As a project manager you would need to have some technical know how. I am not saying you need to know the inner workings of a compiler,but at least to know about let’s say the .NET framework, databases,web development. The more of these you know the better but at the end of the day is not your Job. I am not talking about project managers that are technical leads, i am talking about PROJECT MANAGERS, with the raw sense of the word. The kind of people that where perhaps business analysts and became project managers, that deal with clients and plans, and changes to requirements, and costs, the business case and risks and manage the entire process from let’s say a higer position. Not the type that give out orders but the type that will hold a developers project meeting and see first hand why things are going good or bad and how it can be fixed.
I think both positions have a logic to it and i am sure that there are people out there that became PM’s from both positions. Now which is the best and most suitable i don’t know.It depends on the person and above all the experience, the developers and the clients they have to deal with. A good Project Manager at the end of the day is someone who can deliver a project to time,cost and quality he’s background will only help him overcome obstacles and to avoide mistakes done in the past.
What do you think?
Category: Business, Project Management, Software
By Andreas Maratheftis on Tuesday, 27 of May , 2008 at 5:25 am
First of all, apologies for not updating this site for some time. As i said in previous post i came to Cyprus and i am really really busy. I managed to fit “2 feet in one shoe” as we say in Greek which basically means that i have too many things to do. 2008 is goign to be a difficult year. Among other things, i have a wedding to plan, planning a honey moon, making architectural changes to my house, not to mention looking for appliances,kitchens,furniture, looking for a car and trying to juggle work issues. This is where good management skills come in to play, ONE THING AT A TIME…..
However i am not complaining, everthign is going well (so far). I am currently working as a Microsoft Dynamics Navision consultant which involves a lot of studying and reading up on training materials which it is intense because the software is massive! Colleaques here are always happy to help and solve questions both theoretically and practically.
Something that i found odd about Cyprus and something that i was warned about in interviews is that user’s are different in Cyprus, they have a different perception of what a software company has to offer them and it’s responsiilities to them as a client.
I found that odd, why would Cypriots be different. I disagree on the issue. User’s are user’s. It doesn’t matter if you are in England,it doesn’t matter if you are in the US,in Greece,in Italy. They only difference is culture. Which- maybe differentiate them in some factors. They many not be so politically correct as the British, or technoligically adapt as the Americans etc, but user’s at the end of the day are the same.
You will find the same difficulties with novice users, expert users will overcomplicate requirements, others will just know exactly what they want and others will change your requirements completely throughtout your project lifecycle.
Startegies that i usually use to minimize the above effects are:
- Document and ask written requests of changes to requirements.This can be on a form (for large projects) or by e-mail.
- Use an online issue management (used to track bugs )software where users can log-in post a message,attach a picture or a doument. These can then be assigned to developers ,PM’s ,BA’ etc.
- Use paper or (even better) clickable HTML prototypes to show users what the software will look like.This helps to catch changes and ambiquities to requirements early on.
- Become a user. Work from the client side if you can for as much as possible.This helps to understand the users better by working with them and understanding how they and the business do things.
- Record and document everythign in meetings and converstation.How many times did i forget something because i did not document it correctly or forgot to do so.
- Enforce a process. Clients re just happy to phone up anyone,even developers to ask for changes, and alterations. This is a no-no. Issues have to be filtered accordingly and clients and your staff need to adhere to the process in place. Because if it happens once it will happen all the time and then you will have a chaotic situation in which clients will be asking for requirements from the wrong people, these will not be documented correctly and then you as a professional will be exposed.
Practically of course this is do-able. You just need to be firm and set a bureaucracy that everyone follows. Of course this should not affect if you are let’s say using PRINCE2 or Agile because even these are processes and for them to work properly everyone needs to understand them and follow them correctly.
Category: Business, Software
