Although I can associate a project with a programme or use the parent project as a programme project, it would be useful if PPO had an explicit concept of a Programme entity, with its own unique fields. It should then allow projects to be associated with a programme and should also provide programme specific reporting.
Date
Votes
3 comments
-
Permanently deleted user As of version 3.4.0 users can now make use of a specialised programme entity.
For more information on how to set this up, please see this Knowledge Base Article.
-
Permanently deleted user Now that I am making use of the Programme entity, it is not quite meeting my expectations. Although it is an entity, it is not a 'first class' entity or a strong part of PPO's entity hierarchy as I was expecting it to be. For example, it is not really a parent of the 'Project' entity, it is simply something that can be associated with a project. I had hope that I could create filters on the Programme entity which would be pervasive throughout PPO but these filters only apply on Programme pages, they have no impact on the list of projects displayed on the Project List page. Therefore, all my filters still need to be defined on the Project entity and, on reflection, the implementation of the Programme entity has not really added anything other than the ability to provide custom descriptive information to your programmes.
Have I missed something?
-
PPO Development Hi Andrew, I am sorry to hear that you do not feel the programme entity is meeting your expectations. I'll try to explain what our thinking was around this and maybe that will shed some light on the matter for you.
When we add major functionality like this, we have to balance the various user requirements, the complexity that it adds for users (i.e. the impact on the front-end) as well as the architectural impact on PPO. When we analysed the requirement around this, the main requirements seemed to be:
1) The ability to group projects into programmes: PPO already catered for this with the Programme field on the project entity which is a simple custom list field).
2) The ability to have a programme project which allows for the capturing of issues, documents, risks, etc on a programme level: PPO already supported this through the use of the Parent field on the Project.
3) The ability to capture a unique set of information about a programme (mainly for reporting purposes): This is where the new functionality comes in as you mentioned in your comment.
Our feeling was that the best way to implement the above functionality with the least amount of impact on the application, which was to introduce a Programme entity which acts almost like the Employee entity in the way that we did. We did consider adding a Programme dropdown/combo on every page as well as the report criteria pages, but it seemed like to large a jump and the impact on the architecture would have been to big and it seemed to us that you could achieve the same functionality using chained filters.
By using a combination of filters, chained filters and custom reporting, the current implementation allows an enormous amount of flexibility in terms of what can be accomplished. That said, this was our first pass at this and we may in fact make it a stronger part of the "entity hierarchy" as you call it in a future release.
Please feel free to set up a workshop through the support team with the development team as we would love to get a better understanding of how we could make the functionality more useful to you (and hopefully other users too).
Please sign in to leave a comment.