Does it work with all versions of Excel?
No. pCapacity requires Excel 2007, 2010, or 2013. It will not run with Open Office Calc, nor will it work with Excel 2003.
What type of software development team is it best suited?
Any software development team, whether products development oriented, or business IT oriented, where your work is project structured, and you need to align those projects with the organization goals. It best suits engineering teams of between a dozen up to about a hundred personnel. Over a hundred development staff and you should probably be looking to change your org chart to divsionalize or some other structure. In this case, each division engineering lead would use pCapacity to for planning. Under about a dozen or so engineers, and individuals wear multiple hats depending on the needs that arise. And at that end of the spectrum, the smaller business plan is much more reactive.
Is there a limit to how many skills or projects can be set up?
Yes. You can define up to 100 skills. Going more granular than that for rough cut capacity planning does not return any value. You can define up to 500 projects.
Why just 18 months for planning?
18 months is based on feedback from CEO’s, and VP’s of Marketing and Product Management. It is a visibility window that is realistic to align the organization efforts. Less than that is too short sighted, as the purpose of rough cut capacity planning is right sizing the team skills and headcount to move the company forward to achieve its two, three and five year strategy. All too often companies have good short term planning, great strategy planning but dont align their projects in the mid-term to achieve those objectives. 18 months also covers at least one full budgeting cycle no matter where in the current budget you are. It is also about as far out as marketing campaigns and sales campaigns are planned for. Going beyond 18 months puts you back into ‘wish list’ mode instead of objective planning.
It seems like it will be a lot of work getting project estimates into the model before I can effectively use it?
If this is your current perception, you’ve pretty much stated that your current development roadmap is not objective, and validated, and is probably more a target wish list than a reasoned and achievable plan. Unless you can get some substance behind the assumptions on your projects, you cannot promise delivery with any confidence. Your goals as engineering leader are to move your organization forward. That means working in sync with other teams to deliver value.
How can I do resource estimates without having firm requirements?
If there is an expectation that the function or feature we’re discussing is somehow on the development roadmap that you are aligned with, you are in trouble if this is missing a basic Marketing Requirements Doc. From that MRD you and the stakeholders need to develop at minimum an estimate of complexity, difficulty, and what the project might look like. You may be wrong, but you have to have something that you are agreeing to. Blind acceptance of a delivarable on that roadmap is signing up to be fired.