Introduction
This is the second article in our three-article series comparing BigPicture with Structure apps for Jira.
This article will cover features supporting Waterfall approaches to project management.
If You missed our first article about creating hierarchies – check it here.
Waterfall
Gantt
Gantt charts are pretty much a standard feature for any project management tool. In the case of BigPicture and Structure there are a lot more similarities than major differences, so let’s start witch mentioning them.
Both BigPicture and structure can put Jira issues on the timeline (and store start and end dates in issues custom fields) and create dependencies between issues, that will be represented as Jira issue links. Standard Gantt Dependencies are available (Start to start, start to end, end to start, and end to end), each of these can be represented as a different link type on the issue level.
Based on dependencies and settings applied, dependent tasks can be automatically replanned.
Both Apps allow the creation of Critical Paths and Baselines and edit some of the issues’ data.
But there are also differences.
Starting with dependencies – in BigPicture defining what type of links represents what dependency is defined globally, while in Structure in is defined for each structure. What is more – even a single Structure can have multiple ‘slices’ defining dependencies different for defined issues.
Normally it is not a big problem, as the best practice is to have a common understanding of what certain link types mean across all Boxes/Structures etc. That being said, Structures’ ability to create a more granular configuration for dependencies is often useful when introducing Structure to environments, where links were used inconsistently – in BigPicture it would require to redo links to make them consistent, while in Structure it can be addressed by configuration.
Another difference is how parent tasks grouping other tasks are represented and handled. In Structure There are two options:
- Parent tasks can be treated as normal tasks, and have start and end dates set independently from the start and end dates of child tasks
- Parent tasks can be used as a group – with start and end dates dependent on the start and end dates of children’s elements
In this area, BigPicture is more robust. Parent issues are always grouping child issues, but start and end dates can be determined in multiple ways based on a setting called “period mode”. There are four options:
- Auto top-down – start and end date of parent issue take priority over children issues. It means, that the BigPicture will try to fit all children elements within the parent issue, without changing the length of issues. If planning all children elements within a parent will not be possible – BigPicture plan them to fit within the parent, even if that means going against dependency, indicating any potential problems. This option is useful e.g. when a certain phase of the project has to end at a specific date, even if it means limiting the scope of the phase or project. Using auto top-down BigPicture will never change the start and end dates of parent issue, based on changes in children issues.
- Auto bottom-up – start and end date of children issue takes priority over, and determines parent issue start and end dates. The setting is useful when we are not planning on the parent level, but the parent is just used to group child issues, and delivery of these children issues is planned for a specific time. It often happens in Agile, where Epic is Parent, but all planning is done on the story level. This setting allows us to plan all Stories and check when the whole Epic will be delivered.
- Manual – start and end dates of parent and child issues are set manually, and are independent of one another. BigPicture will still indicate if the child element will not fit into the parent issue on the timeline.
- Lock – in this period mode issue start and end dates cannot be changed.
Period modes can be set for single issues, groups of issues, and whole Boxes, allowing for high flexibility.
The last Gantt difference, that will be mentioned here are Baselines and Scenarios. The structure allows for defining multiple Baselines with different dates. Thanks to that, snapshots of plans in different stages of projects can be saved as Baselined – e.g. Initial plan, plan after analysis, plan after CR 1, etc.
In BigPicture only one Baseline can be created. But there is an additional feature of scenarios that makes it possible to make ‘test’ changes in the plan, without affecting the actual plan. Users can create a scenario, play around with the plan checking how certain changes affect it and if these changes seem to work for them – merge it to the main plan, and update it with changes made in the scenario. If the Scenario does not seems to be better than the actual plan – it can be discarded.
Resources
BigPicture has a whole separate module dedicated to resource planning, that allows planning tasks for Individuals and teams.
Both of these options have similar features – the main difference is that resources available for teams are the sum of users assigned to the team. The number of users, percentage, and period of their assignment can be edited.
Each user can, in turn, have a different workload scheme (full time, half time, or any other that might be needed) and a holiday plan (with holidays e.g. for different countries and extra working days on selected weekends) assigned. On top of that additional days off can be added and user efficiency can be edited.
Thanks to that kind of “layered” definition allow for full flexibility when defining resources available in the Box.
For each resource, whether we are in a team or individual view, BigPicture provides a timeline view with information about total capacity, remaining capacity, workload, and issues assigned to each resource (displayed information can be configured). Additionally, the workload of unassigned tasks and totals for all displayed resources is visible at the top.
Shown information is color-coded, indicating where attention is required, due to overallocation. What is more, overallocation can be calculated, depending on configuration, based on the Original estimate, story points, or remaining estimate (that takes into account time logged on the issue).
Information can be displayed in different aggregations (daily, weekly, monthly), dependent on the precision, with which work is being planned. More details on where these values come from (both the workload and resource capacity) can be accessed by clicking on the chosen number.
Thanks to the possibility of displaying issues on the timeline in this view, they can be easily replanned if we see some issues with resource availability – either by reassigning them (simple drag and drop between users or teams), moving on the timeline or changing start and end dates. The downside is, that in this screen we do not see dependencies between tasks, so moving one, we risk moving multiple tasks that are dependent on this one. This was addressed by adding a section to the Gantt module, where simplified resource information is available. Using this view users can check how scheduling changes impact resource allocation, and other issues via dependencies.
The Approach taken by creators of BigPicture allows to seamlessly perform team and individual planning (together, or just one of these – depending on needs) with quick access to source information.
Structures features related to resource planning and management are less developed. At first sight, they look similar to the resource section in the Gant module in BigPicture – it is also available under the Gantt chart, it also does not provide more details than the amount of assigned work to the resource and color-coded information in case of allocation.
Structure understands ‘resources’ differently though. In BigPicture only the user (Jira assignee) or team can be a resource. In Structure, we can pick a field, and values in this field will be treated as a resource – issues with a certain value in this field will be treated as assigned to this resource. on one hand, it gives a lot of possibilities – we can have a field representing the individual user (like assignee), team, but also some other resource. E.g. In case, we have an issue that requires certain hardware, like a tablet with a certain OS version, to be performed – we can store this information in the dedicated field. Doing that we will see for how many hours each hardware piece will be used each day and see if we do not have any bottlenecks there.
It is a powerful feature, but sadly only one field can be configured to be treated as a resource source at the moment. If we want to plan on multiple levels – individuals, teams, etc. we would have to change the configuration of the Structure each time we want to plan on a different level, which can be non-intuitive.
When it comes to capacity – there is an option to choose a work calendar (only one – so in case of e.g. employees in multiple countries with different holidays – configuration would be troublesome). The structure allows to set the default value of resource capacity that will be applied to all resources, but for each resource, this value can be manually overwritten.
Additionally, for each resource, we can define the start and end date of availability of resource, and percentage capacity, which will multiply capacity by the defined value. This setting allows to address some cases like employees working part-time, absences, etc., but it is not as robust as BigPicture features.
In general – BigPicture has more features and seems to be better thought out. Structure seems to be the better option in case, where you want to plan the use of non-standard resources, like hardware, rooms, etc. But even this is not straightforward.
Summary
Both Structure and Big Picture areas described in this article are the most robust and complex elements of these apps. Matching available features to your requirements may be a grueling task. I hope the content of this article will be of help!
The next article will cover support for Agile methodology and an overall summary.
Have any questions? Contact us!
If you would like to learn more about BigPicture, talk about the best way of using the tool available in your company, talk about possible training or implementation help, and remember that in Genius Gecko we are the experts in this area. We are working with BigPicture almost from the beginning and we are probably the most experienced people in the world currently when it comes to BigPicture project management. We might also add, that we are not the most expensive! ?
Don’t hesitate to reach out to us for a free first session during which we will help you get the most out of this amazing Project Management tool.