Naturalprojectmanagement

My Journey here...
Thank you to you all for choosing to spend some time with me today.

Today for me is a bit of a hall mark.

Last year I attended Web Directions south 06. ...

Did a lot you guys enjoy last year as much as I did? I just thought it was fan-tastic.

Last year was a very special year for me. I went to this conference, and I had a bit of an .. well
an epiphany.

For many years I pursued perhaps the wrong things.

And in all of that hubub, I’d forgotten almost what I actually really loved doing.

And to be honest, I’m not entirely sure that I’ve ﬁgured that out even now.

What I can say though is that last years conference played a signiﬁcant part in getting me
where I should be. And that’s doing what I like and liking what I do. Success will and has in
part come from that moment. Freedom almost if you will.

This year...on Wednesday when I arrived.. my plane was late. About 2 hours late. Flight
lounge coffee just isn’t as good as it should be when you’re two hours late.

So I arrived, and my room wasn’t ready, so I thought to myself.. well... I need to eat. So I went
in search of sustenance.
<click>
I started off by just wandering around through darling harbour, admiring the city scape..

My Journey here...
This place is simply put serenity in a box.

As I was meandering through admiring the nature around me, I’d forgotten that I was actually
in the centre of Sydney.

I was actually just looking for a place to sit, and ﬁnish this presentation, When I thought to
myself,

...gosh.. you know ... this is IT!

Here I am, surrounded by this massive.... monumental structure of a city. Cars, trucks,
buildings, macdonalds,...

And here I am... in this garden.

Where birds rest, and dragons will sneak food from out of your bag while you work on your
laptop.

It’s this exact synergy that I’m wanting to explore with you all today.

This duality of existence if you will. Where structure and rigor and precision, predictablity
can exist. and this little piece of serenity and nature, co-existing, one needing the other for
each would lose if the other were gone.

This is what I want to unpick with you today. A duality that doesn’t naturally exist, but
through the understanding of the other, and a willingness to have each harness the other for
their strenghts, magniﬁcence can be achieved.

So thank you for joining me, I hope you enjoy this presentation.

So here we are.
This place is simply put serenity in a box.

As I was meandering through admiring the nature around me, I’d forgotten that I was actually
in the centre of Sydney.

I was actually just looking for a place to sit, and ﬁnish this presentation, When I thought to
myself,

...gosh.. you know ... this is IT!

Here I am, surrounded by this massive.... monumental structure of a city. Cars, trucks,
buildings, macdonalds,...

And here I am... in this garden.

Where birds rest, and dragons will sneak food from out of your bag while you work on your
laptop.

It’s this exact synergy that I’m wanting to explore with you all today.

This duality of existence if you will. Where structure and rigor and precision, predictablity
can exist. and this little piece of serenity and nature, co-existing, one needing the other for
each would lose if the other were gone.

This is what I want to unpick with you today. A duality that doesn’t naturally exist, but
through the understanding of the other, and a willingness to have each harness the other for
their strenghts, magniﬁcence can be achieved.

So thank you for joining me, I hope you enjoy this presentation.

I spend a lot of my spare time working with horses.

There’s a lot of very powerful people in this venture, natural people, the likes of Pat Parelli
and Monty Roberts, John Lyons....

One of these guys, Pat Parelli has a view that humans and horses tend to have issues getting
on together because they are fundamentally opposed.

Horses are prey animals, Humans are predators.

I started to look into that a bit, and there’s a few really good points in that little statement.

I’ll run through some of those in a second, But the road it led me down, is that perhaps it’s
because of our biological and behavioural tendencies, that we take certain approaches to
how we do our work.

At this very very rudimentary level, We actually do share a number of attributes with
predatorial animals.

Let’s look at a few...<click>

We have Bi-focal vision, giving us excellent capability to judge distance and measure speed.

Therefore affording us great accuracy in our targeting of our prey.

<click>

We have stereo hearing and ears that point forward, again so we can accurately target our
prey.

<click>

Hands that can can hold onto things, some equipped with claws or opposable thumbs, so we
can eat without having to chase our lunch around.

and lastly, and most importantly!...
<click>

Someone
Go Get it!! said
grass?

We are heavily goal oriented, how we approach problem solving, we approach directly
towards our goals.

Any dog owners in here?

When you throw the tennis ball for your dog right, you grab it, <slime> then chuck it for all
your’e worth.

What does the dog do? <anecdote>

<click>

Rather than with the caution that would be more commonly associated with a prey animal say
horses or cows.

<click>

? ?
So what does all this mean?

Well, we’re instinctively goal driven. It’s borderline pre programmed into us to behave in
ways that approach goals.

This almost primal drive we can see at play in almost every avenue of our lives.

We play games that hone our hunting capabilities like my kids chasing each other around
the house, and then tackling each other in turns.

We celebrate that we achive through our goals, and many social success metrics all but
worship those who can achieve more and more goals.

It’s great stuff, because this inate drive, is what powers many of us to do great things, just
like many of us here today. Each of us in our own way wants to catch the big catch.

We are also herd animals too, and for this we care for each other, and share our techniques,
teaching each other how to achive that success.

Look at this conference as an example. Our best hunters are here passing on the
techniques as we speak.

or in my case jibbering on hoping to get through this alive....

<click>

Of course, because we’re very very clever, we came up with the concept of making
something repeatable.

By pre-packaging our methods We can even improve the efectiveness of even this goal
targeted activity...(see how it works?)

This means we can teach others, and they too can experience the thrill of achieving their
goals.

In the modern world this means came up with methodologies, and standards, and
frameworks. And from that wizardry comes things like risk management matrices, and
evaluation tools, and front loaded speciﬁcations, and a million other goodies for us to use to

ACHIEVE OUR GOALS.

<click>

Budget allocations and management
Configuration Management
Reporting templates
Dependancy Management
Resource sheets Schedules
Design specifications
Gateway review Task lists
Risks management Dependency management
Gantt charts Issues Management
Communications Strategies
Benefits Profiles
Outcomes profiles
Business specifications
Functional specifications
Project management is essentially a meta-process. A process for processes, to deliver
sometimes... more processes.

That’s even before we start to discuss the role of the overarching programmes, which contain
multiple sub programmes or projects.

There’s many tools and techniques available for us to use to contain our projects,

Schedules to box out our timing and phasing, and to provide predicability to our outcomes.
Risk & Issues matrices to manage positive and negative impacts.
Communication schedules, which guide us all on how to speak.....
<click>

!

He did it.

So What did we do with all these cool things?

They make sense, can be documented,
They can be illustrated and packaged neatly into cool sounding boxes like Prince 2,
and for those of you afraid of commitment.. Prince Lite!
PMBOK, and MSP and the list goes on...
Well... ﬁrst we drew some lines,

and thought O.K. lets organise ourselves into some work streams.
Then we can have our people demonstrate their super powers in a nice easily plotted fashion

Looks good. OH,
Don’t forget, because we’re clever we can successfully run concurrent work streams so lets have one of those....
That’s great because now we’ve a time saving...

OK...

Still feeling comfortable here, this is all going good.
Lastly, because projects deliver outputs or outcomes, lets have one of those....

there’s our goal there at the end. Rockin.
So having gone through this we can see that it’s possible to easily plan for our efforts,
This type of planning lets us all see who is responsible for what
<click>,
We know what will come out of the process at the end of the day.
We can successfully predict how much this will all cost, and have a nice plan of attack.
We can all be comfortable that our goals will be met, and satisfy our primal need to achieve what we set out to
achieve.
Plus! it keeps our bosses happy because they also feel comfortable because the outcomes of all the activity are
nicely and clearly deﬁned in advance.
It’s great stuff isn’t it?
<click>

But wait! we’re social creatures!<click>

We want to collaborate,
We want to work together!
We’re capable multi-skilled people who also want the opportunity to learn new things as well.

A contained heavily plotted project delivery method doesn’t really work for us.
<click>

Worse still, the demands for innovation and development speed that are put upon the developers and designers
(who are the classic producers in a project) are increasing all the time.

So to enable the teams to be innovative and to produce better faster results, the Government projects need to ﬁnd
ways to manage and lead those teams. To free their potential.

Which raises an interesting point, Why do you have to manage an agile team?

You can safely argue in both directions, and I’m not convinced it’s something you can win.

Agile teams that are in full agile environments, can safely run, particularly in an environment where innovation
is the currency.

But then in the government, it can be enormously difficult to justify anything remotely resembling and R&D crew.

and I guess that’s really starting to get into an argument about how innovation within the Government can be
embraced.. but really that’s for a blog entry or another presentation.
<click>

And I’m sure there are many people here, who have shared the pain of creative crush, and disappointment from
being driven to a result without being sure it’s the best we could do.

“This is a green ﬁelds development people, and to ensure we meet our goals, we’re going to deliver using
prince2.”

or in reality,... run free, just do it this way....and only over there.
<click>

A little
bit about...

I’m going to work on the presumption that pretty much everyone has at least a concept of
what a waterfall project management method is, and what an agile one is.

But so that we’re all in tune, I’ll just walk us through some very typical styles.

<click>

Pure waterfall or traditional techniques:

Waterfall techniques typically are
dependant on having clearly defined
scope, requirements, and most
importantly goals.

Classical waterfall styles;
Classical waterfall styles are very effective when the following criteria are met.
- Clear requirements
- Technically unbalanced development teams
- There is a requirement for the project to be well documented
- Where the development and implementation pathway is clear and linear.

They are terriﬁc for unbalanced skill levels across the project team.
Because of their structure, they also support quality reporting, which is great for large scale
environments.
The structure and preplanning also minimises wasted effort, through prioritised secondary
work streams to be run either harmoniously or asyncronously.

The technique also is the most easily understood, and documentation on how to work this
way is easily available, making skilling of the project team from a tactical point of view very
easy.

Spiral techniques are great for
managing high risk projects.

But essentially wind up being waterfalls
once the risks are mitigated.

Spiral methodologies are a very advanced and purposeful technique, which essentially;

Look at the projects outcomes, and the pre-determined development and implementation
pathways

Then through a process of risk identiﬁcation, evaluation and treatment prioritisation,

Implement essentially what is a waterfall lifestyle for the project, prioritising the work
activities in such a way that risks are treated as an integral part of the project.

It’s highly pro-active, and is highly dependant on the team being able to predict reliably what
risks could be facing the project as it progresses.
<click>

Code and test

This one may upset some people, but this technique is really only useful for R&D shops and
private sector operations.

Essentially it’s an experiment and trial method, where something is built and tested either
by component or as an entire unit.

Goals are expressed as visions rather than as tangible or sizeable outcomes.

Pathways are typically unknown, and risk is handled reactively.

Similarly issues are generally handled using impact prioritisation rather than predict and
mitigate methods.

This is where it gets controversial.

Code and test is most commonly mistaken for Agile. Largely because, and I’m guilty of this,
because Agile projects are commonly run in this mode, because there simply wasn’t enough
understanding and familiarity with the technique either inside the project team or outside of
the project team to actually pull it off. <click>

Agile , Scrum, Extreme

Agile I expect there’s heaps of people here who either have worked a project that runs agile,
or want to, or have heard equally good and bad things about this one.

He’s the new player on the block so to speak.

Born in around the 80’s, primarily from a desire to do rather than document, agile is about
iterative, small step development, rather than what is more typically demonstrated in other
methods.

The agile method minimises risks to outcomes, by taking only small steps at a time, and
uses heavy interdisciplinary collaboration to succeed.

Agile also is incredibly well suited to dealing with ambiguity of requirements, but where the
highest level vision is clear. Oddly enough, even in the biggest most mature enterprises, this
is actually the case, despite vehement argument to the counter.

Regrettably Agile is often executed poorly and has earned itself a bit of a bum rap.
Collaboration doesn’t always occur, social understanding and consensus is lost. A loss that
is typically mitigated through quality documentation.

I tend to be of the school of thought that it’s because on the surface, Agile looks
undisiplined, that the practitioners of it also ARE undisciplined.

Agile in a box;

Because agile is so misunderstood by many, I just want to run through a few basics on it.

Just because agile looks so free form, doesn’t mean that it is.

In fact, it’s far from the truth. Agile methods actually significant cultural and behavioural
discipline amongst all of the practitioners involved.

Some basic characteristics of an agile project are that:

Teams don’t necessarily stay together through the life of the project. Their members shift
and change on the fly to match the required outcome of the work packet they have before
them.

Work packets may not necessarily be complete by the end of a sprint.

Documentation is light weight, but the subject matter knowledge is very intimate within the
practitioners, and in the artefacts they produce.

Visions for what the end state should be in terms of the benefits to be derived from the
delivery of the project are very very clear, but the outcomes and the pathways to get there are
not.

Agile teams also tend to have primarily experts as practitioners, as the development times
simply do not permit much time for training on the job.

So, how do you get agile projects to work if they are so fraught with danger?
<click>

Design Authority
There’s a number of key roles other than the project manager that need to be in place when
using agile.

I’ll not give you a tome of role statements, but just the key ones that are typically left out.

I’ll note also these are roles, and not necessarily entire people, but in larger developments,
they should idyllically be one singular person, or a dedicated and cohesive team.

The design authority is the role that has the ..duh, authority over the design of the projects
outcomes.

What this means is that this is the person who will make decisions about what outputs are
required to deliver the beneﬁts or outcomes of the project.

So this guy, he would oddly enough have nothing to do with the actual visual design or
interactivity design or any of those output oriented things. His sole purpose is to design the
shape of the projects outputs, so they match against the parent vision.

He’s important because without a singular “point of truth” shaping the work, the project
loses its capability to be predictable.
<click>

Configuration
Manager

Next up, to ensure that the work packets are built in the right order, and to manage the effort
balancing across the project team, the Configuration Manager steps up.

The Configuration manager holds two roles. Firstly, the Configuration manager is effectively
the foreman, who determines which descrete work packets are worked upon, and by whom.
Thus he configures the agile teams, packet by packet to deliver the blocks which are to be
used to complete the project.

The Configuration manager also in a very dynamic way, takes the outputs of each iteration,
and passes it back into another iteration until it is complete or it has embraced the latest
changes.

The Agile lifestyle

To complete the picture, there are the work teams.

the agile project often gets described as having a lifestyle, rather than a life cycle. Which
makes sense to me, as practitioners within agile run projects, exhibit behaviours that are
more culturally derived rather than organisationally.

Agile projects like I said before are highly collaborative and iterative. And because of the
speed at which things occur, communication, rest, focus and dedication are crucial.

Theres about 5 activities which an agile teams generally will go through.

The Agile lifestyle
Form

Form:
which is where an agile work team is corralled and tasked with a particular work packet.

These work packets can be all manner of good thing from working on the base architecture,
to front end widget design, to procedural mapping, even documentation!

It’s an essential time for the team, as this is where all the members socially ﬁgure out who’s
doing what, and how they can work together.

The Agile lifestyle
Form
Think

Think:
As the name implies, the think stage is where the team cogitates on what is required of them
from the work packet.

A micro plan is generally sorted out here, and activities are ﬁgured out amongst the team.

The think stage is essential to harness what knowledge comes from the last stage Review,
which i’ll discuss shortly.

Key thing to remember here, is that the think stage only reviews how to attack the problem,
not necessarily the outcome at the end.

The Agile lifestyle
Form
Think
Build

Build:
We all know this one,

We build things here. This is more commonly known as the SPRINT.

Everyone beavers away here, developing, designing, and writing like crazy. Well in a very rapid
fashion.

Daily catch-ups to review output progress amongst the teams, rapid building, lots of low
ﬁdelity sketching, pretty much anything goes here. If you need it, go get it.

The Agile lifestyle
Form
Think
Build
Release

Release:
This one is sometimes overlooked, and you see this manifest itself in the form of unreleased
work outputs.

Agile projects rely on the various work teams releasing their outputs to the “Lego box” once
they have ﬁnished the sprint.

The strength of and agile project is that the work outputs of the collective are shared and
accessible by everyone, rather than discrete single points of failure where knowledge and
outputs are contained.

The release stage is where each team must release its outcomes to the conﬁguration manager
so the rest of the project can see where that particular work packet is up to and how it looks.

<click>

The Agile lifestyle
Form
Think
Build
Release
Review
Review:
When a team ﬁnishes a sprint, there must be a “rest”. This allows the team to recover from
the sprint, and collect their thoughts.

Burn out is something that must be managed very closely, as it’s very easy to see the burning
magnesium effect within the team members.

The Review stage is where this occurs, but it’s not all sombreros and tequila.

As the name implies, the teams must collectively or as an entire project, review what’s in the
lego box now, and work with the conﬁguration manager and the design authority, to
determine what the new work packets will be for the next sprint.

<story about house building>

Connect
ing

Now that we’ve got this understanding in place,

let’s get back to connecting...

Connection between agile and waterfall methods is by no means a simplistic trick.

Despite my best efforts for you now, to make it easy or at least look that way, it’s a tough
job.

In many situations, I’d argue that a hybrid of agile and waterfall is not a very good idea. As
typically it’s a big ask to try to ﬁnd people who can comfortably work in both environments.

Waterfall and Agile are kind of like oil and water.

This is largely because the methods are typically at odds, from a purely tactical perspective.

Agile projects don’t generally have a date for when they are ﬁnished, they work of a
“percentage of capability delivered” concept. Where the exact completion date isn’t really
that important, but what is, is the date when the clock runs out, and how much of the
overarching vision can be delivered by then.

Agile is best suited to :

When building something new, that hasn’t been built before, or the technology is unknown
or unfamiliar, or the teams capability isn’t balanced, and in most cases:

When the development house has no metrics around how many function points can be
delivered by their teams in say a 10 day work period. Meaning...

Agile
Waterfall
Both

The choice for when to use agile, and when to use waterfall or something else typically falls
to the project owner or manager to decide.

It’s important to recognise that the choice needs to be made being highly conscious of what
the project team can handle, and what will best ﬁt the nature of the project, rather than what
is the latest or most marketable option.

The burden of that choice in ideally needs to rest with the entire team. You practitioners
need to be active in supporting that decision as well.

Typically performance metrics don’t exist in Government. It’s not generally known what
the development capability is within a build team in terms of say function points per day.
Amongst other things.

So as practitioners in that space, you have to get in there and support the decisions about
what pathway to take.

This is not to say that agile and waterfall, cannot exist together. And if I’ve learned one thing
over dealing with horses, people, projects technology and everything else, its that balance is
not achieved when everything is the same. you need good and evil. microsoft and osx.
homer and mr Burnes.
<click>

Agile to lead

From my experience, and from what I’ve been able to ascertain from the community, Agile
projects are most effective as children of a larger waterfall project when in the
government context.

Waterfall can even be expressed as being the larger enterprise anyway, because when you
look at the majority of large enterprises, they typically operate in a mostly linear and planned
fashion.

Agile projects to my mind seem to work best in one of the following conﬁgurations:
Firstly:

Where a projects requirements are vague, but the development path needs to be delivered by
a third party like another team or development branch

Or through some sort of service provision arrangement, outsourced development or some
such...

An agile method can be front loaded into a project to reﬁne those requirements and build
concensus about the desired design for the outcomes of the project.

This is particularly useful when looking at websites, or at complex software designs.
<click>

Agile to support
For projects where the requirements are nice and clear, and the general development
pathway are nice and clear, you can use the agile method during the design or requirements
gathering phase.

So in a classical waterfall project, the planning starts, the business requirements get
documented, and written up, and in an the agile design process comes into play shortly after
that.

The design phase would bridge if you like the requirements deﬁnition phase, and the
development phases.

Agile lends itself to the design process, and has been demonstrated many times
particularly in the automotive industry, and in the Media generation industry, where iteration
of design is pretty much the only way to work.

Just to look quickly at the automotive industry, in many vehicle developments, the agile
design method is used to prototype a vehicles overall design, features and form.
And this then gets transferred over to the engineering departments, who would use more
conventional linear development methods to take the outcome of the design phase,

Devise a linear, repeatable construction method, and mass produce a run of cars.
<click>

Genuine hybrid

Lastly, and this is perhaps the most complex way to engineer a blended project.

But the true hybrid, has the potential to be the most powerful, but requires incredible
discipline, and management to actually get decent results.

But the potential of such a project is very very high, because it offers the opportunity to use
the strengths of each method to support each others weaknesses.

It’s particularly good at handling very large enterprise scale software developments, because
resources are available to both execute and manage the project.

This one is a bit involved. Essentially, the basic construct is this. Take a normal waterfall
project, then you task the waterfall project with the development of the core architecture and
primary “big rocks” of the development.

Then as sub projects, use agile teams to rapidly deﬁne, prototype and build sub
components, which can at various stages through out the project, connect back into the core.

Because the agile teams can produce quickly and with limited requirements deﬁnition they
can be used for a multitude of purposes,
- including catch-ups,
-risk or issue treatment,
-capability development or
-value add enhancements, or
-even mid stream research and development.

One example I can think of, and I wish it was a personal case study but anyway..

Related to an installation of a content management system, Vignette. For this CMS, it can be

mm ing up
Su

So after all that,

We’ve discussed the origins of our desires to have methods, and to process drive our
practices to achieve our goals. To meet our primal need to hit our goals.

We’ve reviewed some of the methods that are in play in modern software development, and
explored quickly some of their strengths and weaknesses.

We’ve gone over the agile method, and what’s really needed to get it into action. Noting that
perhaps in large environments, that there are a few extra roles that we may not have
recognised before.
These are the Design Authority and their hands, the configuration manager.

And we’ve looked at 3 configurations which could be used to integrate the two methods
together.

This all leaves us with I guess this question...

Why should we integrate the two, it seems hard.

Well, that decision really is up to you. You need to decide for yourselves what the best
approach is for your project.

You have to look at the nature of the project,
- how well it is defined at the beginning.
- How well the practitioners involved know the process.
- How often the activity has been done before...SUCCESSFULLY.
- Can you even market using an agile approach, or a waterfall one, or a hybrid of the two.

Wh ere are
weh ea ded
now?

I went to John Allsops presentation yesterday about where the web is headed, and technology and what not.

A key point I took away from that typically very energetic presentation was a concept that we should perhaps be
building smaller apps, that do less. Alluding to perhaps that function rich apps may not be the way forward.

Which is a paradigm which is really at odds with what many government applications are about. Typically
Government will look to solve business problems, that is, entire business problems using web technologies to fit
the bill.

And as is typical to that, it’s thinking that isn’t unlike what was seen in the industrial age, where machines would
assist us to live our lives.

Our world now, is fundamentally different from where we as a society were say 20 years ago. where even putting
together a computer was a multi year thing.

Steve Jobs (mac addicts?) proudly announced that his team put together the intel mac platform in 7 months!
where each month his team would release to test a new variant or model. Sounded a lot like iteration to me.

What would it be like if our software in Government was written the same way? Software doesn’t need to be
built in big lumps. It can be built in much smaller function groups or even singular functions, being released to
the production environment every week!

But there lies the problem, particularly within Government. Often the required functions aren’t known. Often the
functions are part of a much more significant process, which is far more complex than one simple function.

Often in government, the deployment platforms simply cannot work the way we need them to work.

I listened intently yesterday also to Mr Andy Clarke, who said something terrific. He was referring to the CSS 11.
and that they were simply just trying to actually do something. So they were trying something different. But is
the government world ready for the current issues to be breached? and ... because of the accountability issues
within Government.... who’s going to pay.

Doomy enough for you? All is not lost. Change will come, just not now. To me, Governments, and many large
enterprises are really just about on the cusp of getting the big IT. I would hazard to suggest that the future here
lies in the souls in this room. It’s our influences now that drive the world in a few years, so we should all be
actively working out how to achieve our goals.

Persistence pays

Persistence pays.

Not every negative view of the approach is a genuine negative.

Fear can drive peoples behaviours sometimes.

I hate the dark, so I gravitate towards what I can see.

Some people can’t really get their heads around what agile is good at, and think it’s bad
because it fails to do what waterfall can. Ignoring that it’s very very good at doing what
waterfall cant.

2. <click>

Be deliberate

Choose wisely which approach you engage with.

make sure you know and have experience or access to the experience of having done it
before.

Projects at the large enterprise level are no small feat. And almost never ever ever cost
under a hundred thousand dollars when you sum up all of the costs involved.

So be careful, and choose wisely. Be risk adverse.... survive to do it again next time.

And lastly...
4 <click>

Be supportive

You are never in a project alone.

irrespective of what cult you follow.

You’ll always have more than one person to deal with. And in the case of large enterprises,
possibly hundreds.

And sadly, there are no heroes in large projects. Because no single person can ever pull
these things off.

So coralle your team, your supporters, and your coffee because big projects are a lot of work
and the rewards are there.

I’ll leave you with a little something I put together once, which was inspired by a horse trainer
who I have a world of respect for, and even if you aren’t into horses, I’d recommend at least
seeing him once. It’s worth the time.

Thank you all very much for spending some time with me.

Good luck and enjoy the rest of web directions south.
<click>

ìPowerful programmes or projects can produce and
promote peak portfolio performance.

To potentially prevent poor project performance,
people promote positive and purposeful practices of
the project management profession.

Thereby positively empowering people for practical
and potent project products.ì

Nod: Pat Parelli, www.parelli.com
Questions? Comments?

Rotten Fruit.

Naturalprojectmanagement

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

Naturalprojectmanagement