ZCOPE Blog

ZCOPE Tip: The „internal“ feature

Even if we support transparency in projects – there are things that should remain „among us“, therefore „internal“. All employees of the account owner automatically have the „internal“ status and thus more rights and access to more data.

But also people from outside of the company can get the „internal“ status, e.g. an agency on friendly terms, with which also confidential information will be shared. Due to the extended settings, certain things can remain within one company: in this case one simply deactivates the reading and writing rights of the corresponding area (e.g. time tracking).

What can be marked as „internal“?

• Tasks
• Dates
• Documents
• Blog entries (of course the corresponding comments are „internal“ as well)

Task lists cannot be „internal“ as there would be too many dependencies in the case of task moving between multiple lists.
Budgets are invisible for not-“internal“ team members by default (this can be changed redefining the extended settings).

The project manager can adjust the „internal“ settings. Only „internal“ project members can  mark elements as „internal“.

ZCOPE Tip: Extended settings

Not every team member should have access to all information resp. the right to write. E.g. trainees should be able to see tasks but shouldn‘t be authorised to create new ones: they get reading rights for this section but the writing rights will be deactivated.

Extended settings can be defined for the following areas:

• Tasks
• Time tracking
• Dates
• Budgets
• Documents
• Project blog

These settings can be determined for all project members, no matter if internal or not. The latter by default have fewer rights – this can be changed with the extended rights.

ZCOPE Tip: Connections (task lists, milestones, documents, blog posts)

In ZCOPE you can connect documents and blog posts with task lists and tasks.

I will illustrate this tip with a case study. Let‘s suppose the task list is called „Design website“ and there is a task called „header image“.

The design company uploads a draft for the image and connects it with the task. At the same time a conversation resp. feedback is started in the blog. The design company writes that the first draft was made according to the requirements mentioned at the last meeting but that it became obvious during the design process that the text was too long and if it could be shortened. Also this post will be connected to the task. The customer sends a suggestion for the shorter text and wants the font colour to be slightly darker. The design company edits the image and uploads the new version.

A corresponding icon will be shown with the task if it‘s connected to a document or a blog post. By clicking on the icon one gets to the latest version of the document or the blog post.

ZCOPE Tip: To start with a to do list

You may start your projects in ZCOPE as you wish, one possible start is the to do list. Here’s a short instruction how we do it:

For this purpose I create a task list and fill it with all the tasks that come to my mind. Once this is done I think of an appropriate grouping of tasks and create new task lists based on that. Then I move the tasks from the original to do list into the corresponding new task list: in ZCOPE you do that by drag & drop, it’s as simple as that.

We used this approach also for a SCRUM sprint: the single task lists stand fort he calendar weeks (CW), where we placed the tasks from the original to do list. In this way we could even image dependencies: What must be finished at first, goes into an earlier CW as the one depending on it. At the weekly meetings we talked about the tasks still open and moved them in a future CW if necessary.

All in the purpose of agile project management changes appeared during the sprint and we had to redispose. Thereto we created new task lists (Sprint 2 CW Y, etc.) and moved some of the tasks from the old sprint (Sprint 1 CW 1, etc.) into them. All the remaining tasks from the old sprint now are in one single task list (Sprint 1) until needed and planned.

Conclusion: The rescheduling was done in very little time, tasks of the postponed sprint won’t be lost, but aren’t in the way. Well, a successful experiment ;-)