In this article I'm going to list a number of practical action to consider when we take leadership of a new team or join as manager a new project. I assume planning is one of the most important thing, so I didn't stress a lot about it. Here I preferred to  emphasize on the "soft" aspects that usually we acquire only with experience.

For the sake of shortness, I wrote the article as a check-list. If needed i will expand the single themes in other articles.

I wrote this list thinking about a team involved in IT work. Nevertheless, I hope that it will be possible to grasp some positive ideas also if the team will be involved in other areas.

• If we must take responsibility of a project or we are involved in it, we need to get all the possible information and, most of all, we must check what is written within the contract (milestones, deliverables, SLA, exit criteria, responsibility areas ... ). Usually ignoring some clauses or even paragraph of the contract may lead to fatal consequences.
• We need to immediately create log of deliverables/tasks that we are requested to accomplish. By creating such log we will be able to have quickly an idea, maybe not so precise, of the situation we are facing. A good starting point is usually the work plan (if it exists), but also interviews with team member and other stakeholders (avoiding however any kind of scope creep). Please note that the work plan (or better the project management plan) must always exist, what we need to do here is to move from the activities on a document to a better control of what we are doing and whar we are going to do.
• Define the objectives of our work. If there is no work plan, create one. In any other case, given your vision and the backlog of work, it shouldn't be so difficult to define short and medium term objectives. Pay attention to the fact that your objectives need to be shared and approved by your team and by your senior management.
• Create a detailed plan. This is really an ongoing activity and it includes the previous bullets. In the particular case we will prepare a first plan that then we will review it periodically during the project. If there was already a plan, then we should review everything with regards to the results of our investigations.
• Define objectives of each team member. Always remember: people before everything. If we know the activities and we already planned the work, then at this point we need to decide who is going to do what and what our expectations are. Objectives will be prepared and reviewed with the interested people trying to follow as much as possible MBO methodology.
• Verify tools that are used and define a baseline for them. Once you will understand what tools are used and what are th tools to add (es. configuration management, requirement management, data model tool..), we stop the "discovery" phases and we avoid to loose other time in experiments. Other tools will be added or modified once we will have clear processes and how the actual tools are usedi.
• If there are subcontractor, remember to verify the contract and the agreed service levels. In different words, check existing OLAs and SLAs.
• If it doesn't exist, set-up a system for managing quality. i believe that you can do the difference in the quality management. The ideal solution is to have an expert fully dedicated to this subject. If it won't be possible, try to organize the work so that this point is not lost. In my to-do list i see the following steps:
  • define peer review processes, then walkthrough ones and finally (only if the company supports them) software inspections. The first two can be easily implemented in every company, the true inspections, on the other side, need a quality oriented culture in the company and an inspection team already set-up (seei software inspections)
  • define work processes, and processes to verify the quality of the existing ones.
  • define KPIs and measurement that we will use to verify how good our work is. Some KPI that is possible to monitor are the following:
    • respect of estimation
    • time to execute a change request
    • time to deliver an analysisi
    • respect of the delivery date
    • defects (for example for line of code)
  • Set up periodical session for discussing lesson learned and brainstorming about improvement of new processes.
• We should define a work tracking system. We need to have as soon as possible a minimal system to track work that is the true done. In other words we need to set up a weekly reporting system to check how time of the team is used. When you link the reports to the activities, usually you get good advices on weakness or strengths of the team. When then you link them to an EV management system, you get additionally a good monitoring of the project..
• Together with accounting system, we need to define a reporting system and a communication plan. That means we should define a set of report that we will use to communicate each other and then define an effective way of communicating.
• We need then to define a strategy for handling the client or other stakeholder. Based on the input, it will be important to define such strategy. I think that, with regard to this, the best is to follow PMBOK processes  related to stakeholder management in the communication area.
• We need to create a CMS portal or at least to get one server for the team and the comunication with other stakeholder. If possible it is better to create a site to use as focal point. Alternatively we will put everything in a server. Basing on my previous experiences, managing a portal is not so difficult and speeds up quite a lot the work. For most expert it will be possible to use advanced communication portal (IBM, Alfresco) but old Sharepoint or Joomla will go as well.
• Using the portal, we need to create a project notebook (or team notebook). We must documen in a more or less formal way (depending or the company/project) all the decisions, all the methodologies, all the standards that we will use. Referring on the PMI, the project notebook will be an extension of the project plan.

The ones presented up are clearly general notes. Some of them can be avoided while some other should be considered and managed with particular attention. However, taken all together, i think they give a guide and a way to proceed that will then allow to enter into the things and avoid to simply react.