I have enough experience to formulate my own rules I stick to in project management or in general, any work. In my opinion, these decide whether a project is successful or... is not. Therefore I will pay attention to them in any project I work on and make sure other team members and stakeholders do as well.
- First of all, I look at any project and product through its stakeholders or users' eyes. This is probably the single most important thing as users not being happy can overshadow any achievements. And the other way round: them being happy and the product adopted well eclipses any shortcomings. Direct feedback from users is invaluable and often constitutes an advantage over the competitors.
- Defining goals is crucial for a project to be successful. Without precise goals a team will soon lose their focus and the rusults of their work will almost certainly not match the expectations. With clearly defined goals a team can concentrate on finding best ways to achieve them and not spend half of their time actually defining what needs to be delivered. Once defined, you need to distribute goals too.
- Redundand work should be avoided as it wastes people's time and company money. Especially long meetings not bringing any value should be shortened or removed from the schedule. Working with the same people on multiple projects lets them perfect the processes which is valuable not only for their project but also for their organisation.
- There is no better way to lead than leading by example. This makes team members accept you as an honest person and often follow your example. If more team members behave this way there is no need of setting too many explicit rules. It just works because it is the most natural way for people to cooperate. So: treat others like you want to be treated and follow the rules you want others to follow.
- That being said, some rules are needed in every project and every team. They can be minimal but should be adhered to. Otherwise the more disciplined team members will soon lose their motivation as they will be influenced by some less ambitous ones. A Project Manager needs to make sure such rules are defined, followed and updated, if this serves the project well.
- In my work, I try to understand tasks down to little technical details. This lets me envision relationships between tasks and better estimate consequences of scope or schedule changes. Lack of such understanding often causes delays and escalations in IT. A Project Manager should be able to communicate scope between teams and to external stakeholders and answer their questions.
- The above is one of the reasons for which I often test products of my projects myself. This lets me understand my product better, discover common mistakes and ways to avoid them while one more pair of eyes checking quality never hurts. Besides, using your own product is a perfect way to understand its most common usage scenarios and what end users might feel about it.
- When talking to any team member or stakeholder, I focus on their expectations and try to understand what they consider most important aspect of the project. I try to speak their language, a different one when talking about technical requirements with developers and a different one when discussing website appearance with the project sponsor.
- Apart from project scope and technical details, I seek to understand people's and teams' roles, the "who's who", to let me prioritise their requests. This is especially important in ongoing email communication with often disjointed messages from dozens of people. Even best answers delivered too late are often worthless. This is why prioritisation is crucial.
- Finally, people in every team should develop their skills while working on projects. They do this best when taking on new tasks and learning from colleagues with more experience in a specific area. Working with new tools, trying new ways to solve problems pays off in a longer perspective, especially in the IT industry. Plus it is a solid way for a company to keep its employees happy.