As it becomes apparent, tool that can be used in combination with conventional resp. already adopted programs have a higher shot at being accepted.

Therefore milestones and dates in ZCOPE can be imported into the own calendar (Outlook, iCal, Google calendar, etc.). These programs are used a lot and thus reminders are in effectively noticed. Additionally it’s possible to be reminded by e-mail of course.

In ZCOPE, task lists, tasks, milestones, dates, budgets, documents and blog entries can be tagged. You may want to apply a unified wording as to find all the relevant elements. Best to have a look into the existing tag cloud if an adequate term has already been used.

By experience I can say it is always good to have several tags with one element. It helps also with inconsistent wording – via one of the possible terms you mostly find something.

Besides the positioning of task lists and tasks according to their priority, it‘s possible to prioritise via tags as well: we use e.g. „important“, „urgent“ and „earmark“ in our further development project.

The tags can also be renamed or deleted, if you misspelled a word or don‘t need the term any longer.

A small tip for the tagging outside of ZCOPE: on del.icio.us I work with e.g. „2read“ oder „2blog“. Over time a quite considerable collection arised in this way – in case creativity leaves a lot to be desired ;-)

What tips and tricks do you have when it comes to tagging?

Thanks to the authors of the Manifesto for agile software development the term agility has become increasingly popular in the last 5 years. The Manifesto states explicitly what they believed, their core values and enduring purpose. It pushed the agile software development movement. The Manifest established a set of 4 simple rules or core values for developing complex innovative systems. Following the co-author Jim Highsmith with his book “Agile Project Management” we can easily apply these core value statements to Agile Project Management:

Responding to change: Don’t plan. Explore.
Reflects the agile viewpoint to focus on envision-explore not on plan-do and on adaption rather than anticipation. Innovative projects are characterized by envisioning and exploring rather than detailed planning and task executing. Thus the team has to see changes as a friend not as an enemy of the project.

Working products: Documents don’t work. Products do.
Describes the idea of delivering iterative versions of the real product according to the motto: “Documents don’t work. Products do.” With the side effect of lowering the cost of change or failure following the theory of early failure detection: “the earlier the cheaper”. In the field of Software Engineering the advantages are common known: Requirements are changing and large design and concept phases leading to massive failures, because then the linear implementation of the requirements without feedback and reliable tests often ends up in a disaster.

Customer Collaboration: Confidence over Contract Negotiations.
This value describes the importance of a close partnership to the customer in which each person has a specific role and responsibility. To prioritize the human aspects of a partnership more than it’s contracts means to find a collaborative relationship to the customer marked by confidence not driven by contract disputes. Because the goal is to deliver value to the customers, the customer defines the requirements that provide value and the business objectives quantifying it.

Individuals and Interaction: Making Participatory Decisions.
This value focuses on the importance of skilled peoples within agile projects. Without the right people all processes and tolls won’t produce results. Tools are very useful for speeding up efficiency but rely on knowledge and capabilities of the team. “A fool with a tool is still a fool!” The agile movement supports the individuals with the concept of self-organization, self-discipline and respect for the individual. Attaining this value is one of the most difficult in practice. The team has the autonomy to organize itself to fulfill the requirements in a best possible way. That is not common! At the end it’s a part of a new project culture, a new type of leadership that has to be implemented with lots of experience, discipline and social competence.

So let’s go for it ;-)
Yours,
Oliver Pretz

I found some very tricky job interview questions in Jochen Mai‘s blog karrierebibel.de, here are the ones I find most interesting:

• How do you know you did a good job?
• How do you think about being managed?
• When was the last time you broke the rules and why?
• What will your colleagues learn from you?
• If I consult two of your former colleagues – a friend of you and a person who‘s not really a friend of you – what would both of them say about you?
• If we hire you now: what will be your first actions in the next 90 days?
• What do you expect from a company you invest your talent and time in?
• Which of your qualities is the most misunderstood by other people?

Some headscratchers, right? But what would be even more interesting for me are the questions the other team members (same job and subordinates) would like to ask their soon-to-be-colleague…

What would you like to ask?

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 ;-)

But trust us, we know how to calculate. A little bug in the site moved the image too far left. The correct display is of course this:

Consultant Dirk Ploss lists on ibusiness.de some prejudices that still haunt the heads of numerous businessmen (comments by me):

1. Innovators are squanderers: they are paid to do things – and not to bother about new products.
Some entrepreneurs don‘t tolerate the slightest thought „out of the box“, as it‘s not daily business. And that‘s what they pay their employees for, at the end of the day. That goes on until the business of today becomes the business of yesterday and they need some good advice how to generate new ideas in almost no time.

2. Innovators are ungrateful: they are unsatisfied with the status quo.
If the status quo gets criticised, that undoubtedly means one thing: the employee criticises the management. Because they know best and are always right. Always right until they are wrong, that is.

3. Innovators are troublemakers.
New things confuse the flow of the entire company. As long as each and everyone knows the ancient procedures by heart, nothing can go wrong. Until it goes wrong, that is.

4. Innovators don‘t turn to account: they don‘t generate an immediate ROI.
Some people don‘t see further than the end of their nose. If it‘s not successful right from the beginning, it can‘t be of value. And quick wins are all they believe in. But keep in mind: it‘s not a nice sound when the (mostly a lot more successful) mid-or long-term wins swoosh by.

• Right in October ZCOPE won an ebiz egovernment award.
• In November we were contacted by the busiest project manager of the world: Santa Claus.
• ZCOPE was available in English for some time and on the 1st of July 2009 also the website was internationalised.
• Still in the same month, on the 22nd of July, ZCOPE started in the first group of the XING Social application Partners – as the first and so far only partner from Austria.
• Since the official start there have been eleven bigger and smaller updates.

We’re proud to have achieved so much in the first year and look forward to an exciting second year!

Birthday promotion – we have a present for you!
An eventful first year with ZCOPE closes, for us a reason to celebrate. We would like you to celebrate with us, that’s why we had the following idea:

Until the end of October ZCOPE is offering the BASIC plan for 50% of the normal price: € 24,50/month instead of € 49/month. For a whole year.

Create your own account and enjoy the advantages of the BASIC plan at the low price:

30 projects, 6 project managers, unlimited users and 10 GB file storage. In addition the features time tracking, project templates and data export. And for further questions you have the ZCOPE support via email.

The line sounds better in German („Wer schreibt, der bleibt“) and I hated it every time my ex-boss cited it. But he was and is true.

He told me a little story, how he learned the importance of recording:

When he was a teenager, he worked in an industrial plant in his holidays. The haedman came and showed him how to do process the work piece.
As a lot of work pieces were done, the department head came to check the work. And realised all the pieces were processed wrong. He called the headman and confronted him with the problem. The headman accused my ex-boss of having misunderstood the instruction.
My ex-boss was shocked but… fortunately he had kept the sample that was used for the explication (easily recognisable as it was an already rusty piece). And he had processed all his pieces exactly as the sample. So the headman was to be blamed and not him.

Some things should be recorded – independent if one has a malevolent headman or not. We cannot momorise all what we do each day. And after a few weeks most of the memory is gone anyway.

What is it you always write down and why?

There‘s one blog in my RSS feed that started to have the same character in the first 5 lines, so I only see the header and these useless lines in my feed reader. If I want to know, what the article really is about, I have to got to the blog.

To say it in a roundabout way: this is not a wise thing to do. It annoys me.

Now I could cancel my subscription and never come back. The guy from the blog would never know why I left.

We may say it deserves him right. But maybe he deserves a second chance. So I could write an email or a comment telling him that his new way to write articles will cause to stop me reading his blog. Maybe he switches back to the old quality of postings?

Canceling the subscription would take me seconds, writing a feedback some minutes. Thus, whatever it is, it must be of worth for me to take the time for a negative feedback. I guess, we should keep that in mind the next time an „annoying“ (because negative) feedback comes in. It also shows that the product, the service means something to the sender.

I don‘t remember who said it, but he‘s absolutely right:

„Complaints are business consultancy free of charge.“