Project management: A typical project

A description of a typical Naviga web project. What roles? Who does what? Not mandatory in all parts, but an overview of potential members that could be involved in the project.

Project members

• Client members

  • Project lead

  • Web developers

  • IT

  • Editorial

• Naviga implementation members

  • Project lead

  • Technical project specialist

  • Web developers

  • Sysops

Client members

Project lead - The clients project lead, ideally someone from the client who can make decisions and knows their products and the goal of the project.

Web developers - One or more developers that are active participants in the development of the project.

IT - The clients IT department is typically involved when it's time to go live, helps out with DNS.

Editorial - The best projects also includes editorial staff, those who will actually work with the sites when they are finished. Good for input on features and functionality throughout the project.

Naviga implementation members

Project lead - The Naviga project lead normally is overall responsible for all the parts of the web project, timeline and to organize the different parts of the project. Project lead may be the same person as the account manager.

Technical project specialist - The Naviga tech lead normally is overall responsible for Dashboard, Writer and Open Content configuration. With a very good understanding of the technology and features of the different parts of the products and environments.

Web developer - has with good knowledge about Everyware, Everyboard and all other packages in Naviga Web. The Naviga developers knows Open Content and how to integrate with the other content products. Naviga developer can be scrum master and facilitate daily standups and suggest the leads in project planning.

Sysops - A Naviga sysops (sometimes called devops) is active during the technical setup and golive to helps out with setup of different environments. Web server configuration, load testing, DNS, caching and go live.

Standups and meetings

At the start of a project we normally have 2 week sprints with daily standups in the morning, max 10 minutes. Before the start of the sprint we have a sprint planning meeting where Infomaker Project lead, Infomaker Tech lead, client Project lead and client Lead developer are present.

When the sprint has ended we finish it with a meeting where everyone is present and developers demo the resolved issues for the group. If a issue is approved all is well, if more work is needed the issue is reopened.

Version control

Git is used, during development we typically use a dev branch for most of the development. If a bigger feature is developed create a feature branch for that feature.

Later in project and after go live of the public sites the master branch is the production environment, we deploy via tags on the master branch. Feature branches is used for all changes at this stage, branch from master and merge in to the test or stage branch to test in AWS environments.

Environments and deploys

Every developer has their own development environment, in AWS we have a test, stage and production environment. Not all customers feel the need for a test environment and just have stage and production.

The production environment is not set up at the beginning of the project, when the projects nears completion it is set up and made ready for deploy.