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 Thursday, 21 of February , 2008 at 12:48 pm
I’ve been to a couple of IT Project Management and Business Analysis interviews myself, so I thought that it would be a good idea to share the experience. Most of the interviews roughly are the same and most of these I get in most of the interviews I have been. I am not going to try and answer these questions since I think It’s knowledge specific and it just comes down to what you believe and what you have experienced until now. Search my site, you will find a lot of the answers in my posts and articles. However feel free to add more in the comments.
Am not going to say how the interviews really start etc, it is usually some form of ice-breaker, tell us about yourself, “we will go through your CV and ask questions on the way etc, it varies.
The most usual questions I get are:
Business Systems Analysis
1. What is requirements analysis and why is it useful?
2. How would you document requirements?
3. What are the typical sections of a requirements document?
4. Given this case studies (you will be given a small scenario) write a use case for it?
5. How would you prototype this scenario (base don the above)?
6. Is usability important and why? How do you test it?
7. What tools/techniques do you use during Business Systems Analysis?
8. How do you run a Requirements Workshop?
9. How do you keep clients focus in a Requirements Workshop?
10. Why are functional specs important? Write an outline of a functional spec? Does this contradict agile beliefs? if yes why?
11. Given this scenario build a Swot/Pest /Rich Picture diagram?
12. Given this scenario build an Entity Relationship diagram or a DFD or a UML activity diagram.
13. Changing requirements how do you deal with the problem?
Project Management
1. What is project/feature/ scope creep and how to you deal with it?
2. Why do projects fail? What are the usual reasons?
3. As a summary describe the Agile Manifesto?
4. What is Scrum/XP/Chrystal/RUP etc? What is it’s main methodology?
5. Agile vs Structured project management what would you recommend?
6. PRINCE2 and it’s benefits to a project?
7. What is the Project board? What is a business case?
8. How does PRINCE2 handle risk?
9. How do you monitor your project?
10. Describe project XYZ was it a success or a failure and why?
11. Have you ever had a failed project?
12. How would explain the agile principles to your client?
13. Agile project management and fixed cost projects. Is it possible?
Add more to the comments, any questions contact me.
Category: Business Analysis, Othe stuff, Project Management
