Naturalprojectmanagement

Natural Project Management

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

0 comments

Notes on slide 1

1 Group