I'm currently a Business Analyst who's shifting to a new company as a Project Coordinator. I have done quite a bit of coordination as a Business Analyst in my current company. What is the initial process/checkpoints, that a Project Coordinator goes through before a project officially starts?
I find that one of the most important duties of an IT project coordinator, is establishing a good relationship between the business and the technical resources. A common pitfall of many IT projects is repetitive miscommunication between the business and technical sides. The business often gets an idea of what they believe the final product will be too early in the project life cycle, and the technical department has a completely different view of the final product. Say both teams work independently with minimal communication and progress reviews over the next few weeks. When both teams get together to inspect progress, there is often a vast difference between what the two teams envisioned.
In the interest of not digressing too much, I'll just cover a few more tips very quickly.
1.) Avoid scope creep! - It's always hard to tell the business "No" when they ask for additional features, especially if they seem like they would take minimal effort to add. While some of this is acceptable (especially if the features are vital to the final product), be able to tell the business "No" when scope creep jeopardizes the final timeline/release of the project.
2.) Spend quality time with business, functional, and technical resources when deriving the initial project design (and with the technical lead for domain design) - Another common pitfall that leads many projects to be delayed is simply poor planning. Projects are frequently delayed because of missing or incomplete ideas during the planning process. Bad domain design can also lead to numerous refactoring sessions later in the project's life cycle. Spend quality time with all resources involved to ensure that everyone is "on the same page" and that a solid view of the project from initial development to final product is established before serious development begins.
3.) Delegate! - When you have such an extensive working knowledge of a project, it sometimes seems like it would be easier if you simply did tasks yourself. Again, some of this is acceptable. But keep your mind on the bigger picture. Your role is to help manage, communicate, plan, review, and make sure the project gets done on time. If you try and take on too many tasks, you A.) Have resources that you aren't utilizing aka - wasting resources AND B.) Overload yourself and become ineffective at your own job/set of tasks. If you have resources available to you - use them!
In additional to my own personal experiences (wisdom, if you can call it that!), there are many resources online to help with project management, task delegation/tracking, and other issues you might encounter. And don't be afraid to ask for some guidance from your project manager if you need it. You're reasonably new to this, and learning from the processes of those around you will be vital to your success as a project coordinator/manager at your particular company.
Hope this helped!
Hare are a few basic items a typical project coordinator might own or in which have an active part:
- Facilities: project work location, infrastructure like hygiene facilities, phones, connectivity, safety & security, furniture, utilities, etc.;
- Materiel: tracking and control of vendors, location of materiel storage to include security, tools with which to conduct work;
- HR: subcontracting control, onboarding personnel, initial training around safety & security and whatever else to acclimate everyone to the project;
- Archive of various documentation that will be developed;
- Contact lists and phone numbers, email addresses of everyone and anyone involved;
- Work calendars, vacation calendars;
- Scheduling meeting rooms for initial planning and kick-off sessions;
- 9. 10.
There are more. I'll add to it as it occurs to me.
The essence of a coordinator role is around administration organization and control.
Start by writing and discussing the Project Charter with the stakeholders
As Marv said, your question is too open-ended. You should provide more detail. For example, are you coordinating a software development project or building a house?
Regardless, it is a good idea to first put together a draft Project Charter and discuss that with the stakeholders and get their feedback. Here is a link that covers the basics of a Project Charter.