Having a 600 HTML pages need to do in Tridion with Angular. Please provide me guidelines how we can do estimation for that type project.
The number of HTML pages does not matter as much as the website structure and relationship between pages, content, and templates, which we often refer to as the "content model."
If I were to run your project, I'd account for:
- Training and Design
- Amount of variation
Training and Design
In most of my customer-facing projects, we'd start with training followed by design workshops to work out system and content architecture.
You'll likely take localization requirements and early website prototypes (or an existing implementation) to create:
- The BluePrint design
- Content Model as part of a functional design
The Content Model will confirm how types of pages you need to implement which influences the templates (or views) and types of content (Schemas in the CMS).
A few years back this included larger designs up front, though by my last few implementations took a more agile approach where the BluePrint was still created up front while the Schemas and *templates (view)s were created in cross-functional teams across sprints.
Not sure on everyone else, but I'd run the basic training in a few days with up to a day for BluePrinting. The technical and admin training would be slightly shorter, but by different groups.
Then my design workshops would be a few days depending on how prepared the customer was (most were ready) and how much there was to address.
However, different implementation partners may have their own approaches.
Your project might also include time to set up environments, get licenses, and set up developer machines. This might take a few days, though some of this is easier with DXA.
Sizing based on the amount of variation
As you work out the page types (variations of pages) and varieties of content, you'll end up with a list of Schemas to create along with ways to render them ("templates").
Your estimates then depend on how fast your team can create these and confirm them with content editors. For example, I knew a great project manager that would estimate a day or so per "template" per implementer, but again it depends on your team. In the end, it's all about mapping fields into a new or existing design.
Note that the business and designers are probably less interested in technical templates and Schemas per se, and more about page types. However, they'll often call these types of pages and/or Schemas as templates. :-)
This doesn't include automation, extensions, or other integrations, which really depend on the desired functionality. See @BartKoopman's posts on how to tackle integrations for more context.
When I size work with my own teams, we'll focus on actual time spent on tasks and avoid including time waiting for others. We might include more time when uncertain about the type of work though.
And if you can, go for end-to-end setups over "throw it over the wall" designs. This means creating the Schema and rendering logic side-by-side and validating with users that they understand the setup. This can help avoid the odd setup where a CMS user needs to enter a
1 into a field to turn off analytics for a page.
*Note that when I mention "template," I mean coding whatever renders your content, regardless if that's in the CMS during publishing/rendering, in the Web Application, or client-side.