ZCOPE Blog

ZCOPE – How to plan and organize your projects more easily!

Take the chance and see in this webinar how easy you can use ZCOPE! We will show you based on an easy example how you can use ZCOPE in your daily work and furthermore we will answer your specific questions.

We are looking forward to many registrations: http://bit.ly/cKawUp

Your ZCOPE Team

10 months at 10 Euro! On 10/10/10 win a ZCOPE Basic Account for a sensational price!

Recently we’ve informed you about the new ZCOPE version 1.4 and celebrated together our 2nd birthday. But all good things come in? Surely, threes!

So today ZCOPE will take you by surprise with a third fantastic offer. Take advantage on 10/10/10 and win one of 10 x 10 basic accounts (each with a value of 49 Euro) at the exceptional price of 10 Euro. For 10 months!

How to do it: Just register at www.getzcope.com/en/promo. In keeping with the philosophy of “10″ you will have 10 days to try your luck.

Exactly on 20 October 2010 we’ll inform the winners and send them the access code.

The ZCOPE team wishes you good luck and is looking forward to a lively participation!

Core Agile Values

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

Everything You Always Wanted to Know About your Project – But were Afraid to Ask

„There are no dumb questions only silly answers.“ (Marshall Loeb)

This is absolutely right. Most of the time it‘s better to ask than to assume. Questions can ease your life – if you ask them at the proper time.

In my projects, I love to ask questions. Especially at the beginning of a project but there are questions that should be asked also afterwards: again and again. Some people won‘t come to the project manager and tell their needs, ideas, sorrows, problems… So you have to come to them.

Why I believe in questions
A short story why I believe in questions: in my by then biggest project ever there was one big part of the solution nobody in my company liked or believed in. But no one said anything – it was presumed to be the „holy wish“ of the customer. As the project leader, I liked the idea neither – because I didn‘t believe in it.

In the kickoff meeting, I thought about how to address this topic. And I decided to ask a simple question. Directly after the welcome speech (I‘m an „in medias res“ girl) I asked the customer‘s project leader: „Why do you want it?“.

My boss nearly had a heart attack. I heard him breathing rather heavily. The project leader looked at me and tried to find an answer. So I helped him out: „Is it because your competitive, company X has it too?“. My boss didn‘t breath at all. My opposite smiled and nodded. I explained him why my team didn‘t believe in the idea. It turned out they also took it for a bad idea and were happy we provided arguments against it. My boss finally came back to life. The happy end: we skipped the disliked part but got the amount fixed in the offer.

My conclusion from this was: it‘s never dumb or bold to ask – a lot of people are only too glad having the chance to talk.

You shouldn‘t be afraid to ask these questions
I collected some questions that can help a lot and should be asked besides the ones you have to ask in every project (e.g. Will we be ready in time? or Who will do it and when?). Some of them I found in the articles I listed at the end of the post, some of them I‘ve used myself:

Addressed to the customer:

• Why do you want to do (produce, build, etc.) it?

Addressed to your team:

• Do you like working in this team/on this project?
• Is this what the customer wants?
• Do we make money with it?

Addressed to everyone:

• Why do you say that?
• What does that mean?
• What does that mean to you?
• Who‘s of a different opinion?
• Is anyone not comfortable with an aspect of it?
• Who else should join this discussion?
• Do we all have the same picture of the project?
• Is it legal?
• Why/why not?
• Why do we have to do that?
• What will happen if we ignore it?
• If we ignore it – how long would we be safe?
• Do we miss anything?
• Do you have questions?
• What did I forget to ask?

And the million dollar question

• I know you don‘t know it. But if you would, what would be the answer?

So you‘re a project manager now?
I extracted this sentence from an absolutely worth reading story on managementblog.org: „Dumb questions“

„Other people are expected to have all the answers. Project managers are expected to have all the questions.“

Where I found some of the questions:
Top 10 Dumb Project Management Questions (reformingprojectmanagement.com)
Ask dumb questions (goodproductmanager.com)

Storytelling in project management: the right perspective

I’m a fan of storytelling. It’s so much more than only enjoying a well told story.

In private life I love to read historical novels because they tell you a lot about former living conditions and it’s easy to remember the year dates. You learn without being forced to force naked facts into your brain (and I know what I’m telling about, I studied history).

As I learned some time ago – there’s a storytelling in the professional life as well – especially in my section, the project management. One blog I really like to read is „Projektgeschichten“ (project stories. Sorry, it’s in German only) by Sigrid Hauer.

One of the stories is about the right perspective: How can we divide chances from problems? By being an eagle and not a chicken:

• The chicken knows its chicken run. But it can’t see beyond the fence and so all things from outside seem dangerous, risky – they are problems.
• The eagle sees the chicken run from a distance and knows much earlier what comes up. Being far away may prevent a direct action, but it helps to better evaluate the situation.

Sometimes we’re chickens, sometimes we’re eagles. The most important thing is to be able to change our perspective when we have to.