00:01Little bit of background first. As you can tell, I come from Atlanta. A little further east.

00:10I'm from Ireland, I joined Esri 21 years ago, and was actually one of the first projects that I worked on...

00:16...with Jack was the LA project for the city planning of LA. And I'm an urban planner by background.

00:22I manage the federal civilian services team out of our Washington, D.C., office...

00:27...and we mainly cater to large federal agencies and their deployment of enterprise GIS.

00:34Everything from very small projects that are a week...

00:37...or even a couple of days long to multimillion dollar, multiyear projects.

00:43And for the most part, the ideas we're going to talk about today could be deployed on any project size.

00:50We're going to focus an awful lot on the large enterprise projects...

00:55...because they really have some thorny issues.

00:57But I think a lot of the practices that we talk about here are applicable to any project size.

01:03So before we go much further, I'd like to do a little hands-up.

01:07Who thinks themselves as a manager? Who's in the management track?

01:13Okay, who thinks of themselves as being more the technologist, kind of techie groups?

01:18Okay, a little less than that, but wanted to get a sense of where you all are.

01:25Both Glen and I would really like this to be interactive.

01:29If you have to listen to Glen and I speak for this entire session...

01:33...it might be amusing, but we want to learn as well.

01:37So we're making this very, very interactive. We would love your questions all the way through.

01:43If you don't understand what we're saying, if you can't hear us...

01:45...if we use a term that you use differently, shout it out and let's get some feedback going.

01:51So do you want to introduce yourself, Glen?

01:55Yeah. Does that work?

01:58Can you hear me...okay. Just want to make sure; there's a lot of feedback.

02:02So like Gerry, I work for Esri Professional Services out of Atlanta, though.

02:08As you can tell, little difference in our speech patterns here.

02:15I have worked with GIS implementations as a customer for years...

02:22...as a system integrator now within Esri's Professional Services.

02:27Most of my background has been on the utility side, but over the past four years, been in the government.

02:34Kind of echoing what Gerry said, you know, really trying to share out some lessons learned, if you will...

02:41...from a project management perspective.

02:44And please, make it interactive. We'll play off of each other.

02:49We'll chime in, interrupt each other. You can do the same.

02:52We want to make this learning not only, you know, hopefully you all walk away with something...

02:56...but certainly we get some feedback and we walk away with it...some learning as well.

03:02Great. Just also, some other housekeeping.

03:05The slides you're seeing today, they'll be in the packet that you get afterwards...

03:09...so you don't need to furiously take down all the notes.

03:12We are being recorded, so that's why we have to stay miked.

03:15And I think that's getting recorded and sent back to Redlands, and you can get that online as well.

03:21Okay, thanks very much. Okay, so we're going to tell you exactly what we're talking about.

03:29This is the 10 things you're going to learn.

03:34Feedback.

03:36And we're going to try and take each one of these and go through them and present some ideas and strategy.

03:44I think it's that one, is it?

03:52Okay, I think that's better.

03:54We're going to present some ideas and strategies, we're going to try and talk about projects...

03:58...that we worked on, protecting any names, either the good side or the bad side.

04:04And I think a lot about project management is learning from experience.

04:08And so that's what we're trying to do today...

04:10...is bring some of the experience we bring to the table, talk about...

04:14...what we have done, what we've learned, what we try and do afterwards to learn...

04:19...from every project that we do, and give some of that experience to you.

04:23We'd love to hear your feedback about what you also have seen.

04:27And a lot of what you've got up here is not necessarily specific to a GIS project.

04:34A lot of it is solid project management experience and practices applied to GIS.

04:40There are often some nuances, and we'll get into some of those, but solid project management practices...

04:47...and communication and style and breaking things up, focusing on the business apply very much for GIS projects.

04:56So we're going to have one or two slides on each one of these and talk through them. Okay.

05:04Okay, the first one is, it's really important that you understand what it is you're building.

05:11And that might sound a little bit cryptic, but it is critically important.

05:16And we see so many projects get off track from the very beginning.

05:20And so we want to talk a little bit about defining what you're building and your...

05:26...and really focusing on the champion and the ideas that you need to build into your GIS.

05:34So it's really important for you to understand what are the critical things that your customer needs.

05:42And that you build those in a...what we talk about a phased or spiral approach and work with their priorities first.

05:54We find a lot that when we get into enterprise they want to do the big picture.

06:00And I've never seen a successful project that tries to do the big thing first.

06:05We talk a lot about trying to break that down into small, manageable pieces.

06:10And on the customer side, it's really important that an enterprise...

06:14...particularly an enterprise solution, you identify your champion.

06:19Who is going to go to bat for you on the GIS?

06:23And there's a lot of people who do GIS work, but you need at an executive level...

06:28...someone who is your champion, who's going to say this is important to our business...

06:32...and that they are going to stand behind it as you roll it out through your agency.

06:40It's important that you understand that customer and what is their criteria for success.

06:45Because it's going to be very different for different entities and different champions.

06:52When we think about defining success, is it that they have got rid of a problem...

06:59...that's been festering in an agency for ages?

07:01Is it data oriented? Is it focused on a specific project that they want to deal with?

07:08Is it focused on supporting something that the secretary within your agency is very keen to see developed?

07:16Is it focused on a specific conference, or a date, or a schedule?

07:21And see, it's really important to understand...

07:23...in how you drive those things and have those conversations.

07:28One of the things we try and do early is try and reset those priorities.

07:32So as you talk with your key customers and stakeholders, how do you really elicit that information?

07:40And how do you get them to prioritize it, is really critical.

07:45We've been working with a number of customers where the important thing that they need to get done...

07:51...is delivering a dataset online in a very short period of time.

07:57So your first couple of spirals should not be focused on, you know, whiz-bang imagery...

08:02...technology that you saw at the plenary yesterday.

08:04It's, you know, those dots on the map.

08:07The small steps that you need to take to get that moving forward.

08:11And it's critical that you also try and engage them to understand that GIS is going to show a lot of warts.

08:22When you start implementing GIS, you're going to find out that your data is not as great as it is.

08:27You're going to find that people are going to be very threatened by it...

08:30...because it potentially can be seen as a way to reduce staff.

08:35It doesn't necessarily always happen that way, but you might need a different set of staff to run.

08:40So it sometimes can be seen as very threatening.

08:43It's really important to early, early in the project start getting some of those issues...

08:47...out on the table and talk with your stakeholder about what are they really trying to do here.

08:51Are they trying to replace a planning process?

08:55Are they trying to replace how they work with the public...

08:59...and be more transparent, which is a big theme of a lot of federal agencies.

09:03Have they done it in the past, and what didn't work?

09:05So it's important in any good project management to go back over...

09:09...and over again and try and understand what didn't work and learn from those failures.

09:16Do you want to add to that?

09:17Just one thing. I'm sorry, this microphone has been driving me crazy.

09:23Just one thing, I guess, to emphasize on that, as well, from a success standpoint.

09:30I guess probably the biggest thing that Gerry and I encounter...

09:32...and some of you probably encounter in managing your projects today...

09:36...understand that success is going to change over the life of the project...

09:39...of what that definition of success is going to be.

09:43A lot of times we set out, and at the very beginning you identify your clear business goals...

09:48...and you start managing and mapping to those.

09:51And something happens along the way, whether it's a regulatory pressure...

09:55...it's something within the business environment, something changes.

09:59Just make sure you're planning for that...

10:01...and recognizing that that's going to happen as a project manager.

10:05It's obviously your responsibility to identify that and to figure out...

10:09...well, how do I adjust, how do I prepare for that?

10:12How do I change my project to accommodate this new definition of success?

10:17And some of the things we'll talk about later on around iterative...

10:21...management or more of an agile approach...

10:23...we'll give you some tools to essentially do that, but I think it's key up front...

10:28...when you're identifying that success criteria to recognize, here's the success criteria today.

10:34But over a two-year project, that success criteria may change.

10:39And change in administration, change in leadership; you know, your champion...

10:43...that you had there now goes on to a different place.

10:46It's really important that you start to communicate and identify those key building blocks...

10:52...so that you can continue that when that potentially changes.

10:57Next thing we want to talk a little bit about is stakeholders.

11:00And we've kind of looked about stakeholders as having kind of two or three different dimensions.

11:07At one level, there is a stakeholder who is sponsoring your project.

11:11So who is it that is your catalyst, your executive that is going to provide that leadership?

11:18The second kind of stakeholders are the people who are going to build stuff, your resources.

11:22So where are they going to come from? Do you have authority over them?

11:26Are they contractors? Are they being supplied by your IT department...

11:30...and they don't know anything about GIS?

11:32And also, stakeholders are also people who are the decision authority.

11:36Who is the one who is going to fund it?

11:39Where's the money coming from, who is having the decision authority that is the go-to person...

11:44...when you have conflicting business requirements - and you will have them...

11:49...that can help you decide and say, this one wins over that priority.

11:55And it's going to be really critical for you to understand, identify...

11:58...put a name on them, put a face on them, and meet with them regularly...

12:02...so that they're aware of your progress and that you're meeting their needs.

12:09We talked a little bit about who is going to be impacted [by] the project.

12:14So if you're reinventing a process within an agency...

12:18...and you're taking something that was done manually and you're now trying to automate it...

12:22...there is going to be people who are not going to be very happy with you.

12:25And it's really important that you understand who's going to be your supporters...

12:30...and who's going to be your detractors.

12:32And part of good project management is trying to be diplomatic...

12:36...and consensus building and team building.

12:40But at some stage, someone's going to get mad.

12:43And it's important that you understand who that is and what the repercussions are.

12:47So if the people who are funding your project aren't getting what they want...

12:51...they're not the right people to...you know, if they pull your funding, your project's gone.

12:58So it's important to kind of balance those ideas...

13:01...of who is going to be impacted by the project and what the repercussions could be.

13:07We'll talk a lot about change management and risk. This is critical to those concepts.

13:14So who's going to be your detractors, who's going to be your promoters, and understand how that will change over time.

13:22The resources that you need to bring to bear on the project are pretty critical.

13:29But from my perspective, I mean, technology is changing so fast.

13:33The languages that your IT people learn in school are redundant...

13:37...and obsolete by the time they leave school.

13:40I never heard of C# before, and now everyone's working in it.

13:44So resourcing your project appropriately is really, really critical.

13:49Understanding that the technology stack that you have is somewhat directed by the resources you can bring to bear.

13:58You might love to write this great Flex application that you saw on stage...

14:03...but if you don't have Flex developers or you don't have access to them, or your security staff...

14:08...or your IT staff is saying, no, no, no, you can't use that...

14:12...that is the balancing act that you have within your project.

14:16And it's going to really determine how successful you are in that project.

14:20So there's these balances that you have to have between the technology that you want to implement...

14:25...the business process that you want to change, and really what resources can you bring to bear.

14:30One of the projects that we're working on at the moment is really struggling from...

14:34...the internal champion really doesn't have resources.

14:40And they're having to spend an awful lot of their time championing...

14:46...the project to always keep it moving forward so they can get more money...

14:51...and hopefully get resources sometime down the future.

14:55But it's...one challenge with that is relying on outside vendors or business partners or interns.

15:02Interns are great for the right project.

15:05And leveraging whatever resources you can in small, focused steps to make it work.

15:11And I think from a resource standpoint as well, just beyond the development resources...

15:17...or the people that are always engaged in the given project team.

15:22From the minute you start requirements...

15:23...and you start determining really how are you going to meet those business goals...

15:28...obviously you need to have the end users sitting at the table with you.

15:32And you need to get a commitment of those resources.

15:34Otherwise, we have a tendency, and all of us have probably done it in the past to some extent...

15:39...where you're ready to start requirements or you're ready to proceed with design...

15:43...or maybe you're into the validation phase and the test phase, and you're looking around the room...

15:48...and it's all the people on the project team.

15:51Well, all the people on the project team a lot of times aren't the people...

15:54...that are using the application once it's deployed.

15:57So making sure from a resource perspective, those people have real jobs.

16:01They're doing something today maybe in your organization.

16:04They're building as-builts, they're editing documentation...

16:08...whatever the case may be.

16:10But plugging them into the process and realizing they're a critical resource...

16:13...to the project and, from my perspective, they're the most critical resource...

16:18...for the project, because they're the ones that are going to use it at the end of the day.

16:22They're the ones that are going to ultimately determine whether you're successful.

16:26Because if you build it and they don't come, then you've got a problem.

16:30Yep. And I think it's really important you engage early and often.

16:35That means different things to different people, and the engagement strategy is different...

16:39...depending on are you engaging at an executive level, or are you engaging at a midmanagement level...

16:44...or are you engaging at an IT level?

16:47So it's really important to understand your engagement possibilities...

16:51...and meet with them in a variety of different ways.

16:55When we try and work on enterprise strategy...

16:58...it's very important that whether it's quarterly or something more than that...

17:02...that we brief the executives that are funding things.

17:05Because a lot of times they don't have the pulse on what's going on.

17:08They fund things and then they kind of go away and stuff happens.

17:12A lot of times when they turn their back, stuff doesn't happen...

17:16...and you need to kind of keep engaging with them at an executive level...

17:19...and bringing what you need to the table and the resources you need...

17:22...to the table to continue that discussion.

17:26Okay, I think there could be an entire session on this next slide, and there's a couple of slides on it.

17:33In fact, I think rather than calling this ten things you wanted to know about project management...

17:37...we didn't want to call the sessions requirements, requirements, requirements.

17:41One of the things we get engaged on a lot is, we get pulled into problem projects.

17:48So I can usually tell by asking a couple of key questions whether the project is going to be a success or fail.

17:59And it boils down to requirements.

18:01So if we go in to a client and they hand me the user documentation...

18:07...of their PC application and say, That's my user requirements, put it on the web...

18:12...it's not going to work. That's going to be a failed project.

18:16If you go in and I ask them for...

18:20...Where's your requirements set of documents, where's the business process?

18:23Where's the business strategy of what you're building?

18:26And the kind of look at me and they have a whiteboard...

18:29...with some drawings on, not going to be a successful project.

18:35So, and requirements means very different things to very different people.

18:40It's an art, not a science, and we're going to talk a little bit about what...

18:44...when we look at requirements at an enterprise-type project, what are we really talking about?

18:53When we usually embrace requirements, we do it in a variety of strategies.

18:59One of the first ones we always try and work through are a set of workshops...

19:03...interactive, facilitated workshops that bring all of the key players...

19:09...the end users, the key stakeholders, and the people who are going to be building it...

19:14...including the IT department to the table in a set of facilitated workshops.

19:18And those workshops typically should not start...

19:23...sometimes it's easy to describe what you should be doing by saying this is not going to work.

19:27It shouldn't start with a blank whiteboard saying, What do you want to do?

19:31That is not requirements gathering. That is a recipe for failure.

19:36Because all of a sudden you're going to have, unless you've got really good facilitators...

19:41...you're going to be all over the place about what the requirements are.

19:45So at the end of this session we've got a couple of slides that show books and things that we use.

19:53...on the Esri website, if you haven't seen the project support center...

19:57...there's templates for everything that we talk about, from stakeholder strategy...

20:02...to requirements gathering templates, to communication plans on that site.

20:06You should be leveraging that, and we'll give you that link later.

20:11We follow some fairly standard business processes to gather requirements.

20:17IBM has their flavor, all the big integrators have their flavors.

20:20There's great books that you can buy on Amazon about it.

20:23Almost every one of them have their own nuances of how they gather them.

20:27But in essence, they boil down to a set of workshops...

20:30...focused, one-on-one interviews or group interviews...

20:34...and a gathering of what is it they want the system to be.

20:39It's important that you model two different things.

20:43If you are trying to use GIS in an enterprise to replicate existing manual processes...

20:50...or an agency workflow, it's really important to understand what the current, as-is business process...

20:58...sometimes we use the word workflow here.

21:00It has very different meaning, workflow, in the utility industry than others.

21:04So we use the term business process.

21:06So if the idea is that you're in an agency and you're going to be putting up a public-facing website...

21:13...to communicate how money is getting distributed for your agency for targeted programs...

21:20...it's important to kind of think about, how do you do that right now?

21:23If you're a city or state government and you're automating a planning process...

21:29...of how to make notifications for zoning, there's a very detailed workflow...

21:33...of how you're doing that right now.

21:35It's important to capture that as-is and then try and say, What should the to-be business process?

21:44A lot of times what we find when we model that workflow or that business process is that...

21:49...there's all these hoops and back feeding and passing of paper and signing off that has to happen.

21:56And what we try and work through is, how can the technology help that?

22:01How can it help it or can it hinder it? And what technology really needs to be brought into place?

22:08What we try and do is, we use a variety of tools...

22:12...Team Foundation Server, Enterprise Architect, Excel spreadsheets, Word documents...

22:18...are all valuable tools to use to help you with that requirements-gathering process.

22:24And we can talk through a little bit about what we use on our large enterprise projects.

22:25And we have implemented projects using those tools...

22:28But most people get by with collecting their requirements using Excel spreadsheets and Word documents.

22:39...and we've also used some of the more larger enterprise architect-type tools and other ones.

22:45On the business process itself, it's important to try and think a little bit about of the box.

22:50So how can you streamline that process? What are things that you can stop the overlap?

22:55How can you re-create, implementing and infiltrating GIS into that process to support it?

23:04It's important that, as early as you can in the process, that you get the data right.

23:09So one of the ones we tackle all the time is, you've got a database of addresses...

23:15...that is collected for your agency that might be the location of the buildings that you support.

23:21And when you geocode those addresses, they're wrong.

23:25And most people think they've got really great files of addresses, and they're usually pretty bad.

23:33So if you're trying to build in a process early on that captures street addresses, you want to make sure...

23:39...you don't want to wait until you put it in the database to validate...

23:42...that you've got the right address or there wasn't a typo of how they spelled Main Street.

23:47You want to try as early on in that workflow, as they are capturing and inputting that...

23:53...so if they're on a mobile device out in the field in their workflow...

23:57...you don't want to wait till the end of the workflow...

24:00...for them to validate that they've got the right street address.

24:03So workflow and early-as-possible validating data is really critical.

24:10And it's really important to understand GIS is not an isolated island.

24:15It usually lives and exists with many, many, many other systems...

24:21...some of which aren't Web 2.0 compliant...that are, you know, legacy, propriety...

24:27...beasts of systems that have been held together by duct tape.

24:30And you really need to think through, you know, what is the worst case scenarios...

24:35...of how you try and integrate with those databases or those systems...

24:40...and then how can you automate that process and leverage those, and understand those linkages?

24:46So you might want to build a very cool dashboard.

24:50But the data and the legacy systems might not support real-time changes on the dashboard...

24:57...because you're not collecting the data that way.

24:59So it's important...there's lots of conceptual diagrams you can draw at the requirements stage.

25:03It's important to understand the big picture, and then it's important to funnel down and get required...

25:09...focused requirements on very specific ideas.

25:13It's really important as a facilitator when you're doing requirements gathering...

25:19...that you don't be judgmental, which may be very difficult to do sometimes.

25:25So you might want to, instead of asking questions like, Well, why do you want to do that?

25:29It's, you know, talking through what that process is that led them to store it...

25:35...in some sort of database or add these variables, or they want to show 40 variables on a dashboard.

25:44You really need to understand not the technology, not the data...

25:47...is what are they really trying to show?

25:49They're trying to show to the manager the flow of money from the grant program.

25:55And you really need to try and understand what the business process is.

26:00Don't worry about the data schema, don't worry about the technology...

26:05...and really focus on business processes that make sense for them.

26:12And you will get conflicts.

26:15We have been in meetings where we've had the end user say, This is the way I want to change my business.

26:20We're building web-based tools, and we want to integrate GIS to support these types of activities.

26:27And we want to be able to go out to the web and reach into data sources...

26:32...that are current and real time so we can bring them in...

26:35...and do great analysis to meet a specific business problem.

26:39We turn around and have an IT meeting, and they will say you are not allowed...

26:44...to have any external data web interfaces.

26:48So they will be mutually exclusive.

26:50And that's when your stakeholders become really important...

26:55...to talk through about, What is your business?

26:58Is the security so tight that you can't go out to the web?

27:02What is driving the business to need that requirement...

27:05...and how does IT facilitate or hinder doing that business?

27:10And so that's when your stakeholders can come in and say...

27:14...actually, you know, we can go out for certain datasets...

27:18...but there are certain datasets we don't want to go out to...

27:21...or there are certain sites we don't want to go out to.

27:23But we often, as requirements managers and when we facilitate...

27:28...you're kind of like a lawyer negotiating a deal in many cases.

27:33And it's important to have all of the people in the room when you're doing that to talk through, What is the business need?

27:41And you always need to come back to that.

27:43Because what we find is, the business need isn't the technology...

27:47...and it's not about the Internet access in a very specific way.

27:52It's about meeting the business problem.

27:54I've got a critical requirement to do with land-use planning...

27:58...and I need to be able to reach out to the FEMA website...

28:01...to get the latest flood mapping that's available so that I can do critical analysis.

28:08That's the business problem, and all the other players...

28:11...if your executive sponsors really, really support you...

28:15...will work to change their ideas of what you do in the IT space to make that happen.

28:21But you will have conflicts. And it's difficult sometimes to move through those.

28:26But they will be looming and you will need to deal with them.

28:32Usually when we do requirements workshops, we break them into two different categories.

28:39One we call functional workshops, and that has to do with, What is the end user needing to do?

28:47What is their 2, 3, 10, 20 tasks they need to accomplish for this system?

28:55You know, and it might be as simple as, I need to be able to put an address...

29:00...do rings around it to do some sort of demographic analysis...

29:03...generate a report, and send it to my boss. That could be the simple workflow.

29:08It could get, and it will get, a lot more complex.

29:11So we usually facilitate functional workshops that are very focused on the end users.

29:19We usually always try and insist that the IT people come to those workshops, even though they're not end users.

29:25We want them to hear what the end users want. We don't want them off in an isolated place.

29:32We try and bring them early and often to end user meetings.

29:34Now they may not be able to come to every one. And sometimes these are just a couple of days.

29:39On large enterprise projects, they could be weeks or months.

29:44So clearly, this is...if it's important to the enterprise, then all the teams need to be engaged.

29:52The second group of workshops we call nonfunctional workshops.

29:55Those are workshops that deal with things that really the end user doesn't have any idea about...

30:01...security, performance requirements, certification and accreditation needs...

30:08...all the things that really do often belong in the IT space.

30:14Sorry, I should have said under the functional requirements.

30:16Once we've got both functional requirements and nonfunctional requirements...

30:21...we generally hold a third set of meetings dealing with data.

30:26So the progress really should be if you can do this...

30:30...clearly is, functional requirements meetings, data meetings, nonfunctional requirement meetings.

30:38It's difficult and probably not going to be a very good working system...

30:42...if you start off with, "This is all the data I have, I want to put it on the web."

30:47Because that's not really a business need, it's a solution to something.

30:53So, who are the web users? What do they want to do? Is it a lot of interaction?

30:58Are you going to get them a lot of customization? Can they turn layers on and off?

31:01Can they add content to things? That's the functional needs.

31:07The data meetings are about, This is what my business is telling me we need to do.

31:12Here's the data that, in all those discussions that support that.

31:17And so you'll hear things like basemap. So, what is the basemap you're using? What is available to you?

31:22Then you'll hear things like operational layers.

31:26So if you're HUD or Census or EPA or one of the other agencies...

31:31...what are the layers that you own and bring to the table?

31:36And then the third group is layers that you want to integrate in that come from other places.

31:42So those data workshop meetings should be directly focused back to the business at all times.

31:48Why put data in the database if you're not going to be using it...

31:52...or it doesn't really meet a strong business need?

31:57Do you want to add anything on that one?

31:59Just to add on to your last point, I think it's important when you're talking through data...

32:04...and you're talking through the functional requirements, is to understand...

32:07...what information products you're actually trying to support.

32:11So when I talk about information products, I don't always necessarily mean a product...

32:15...something that somebody is going to produce a hard copy of.

32:18Could be a web service that the customer may want to expose...

32:23...to perform a particular function within the organization.

32:26It kind of goes back to what Gerry said.

32:29In a lot of cases, we sit down and we get a list of features and numerous attributes.

32:38And it's hey, here's my data, or here's what I want to start capturing and maintaining in the future.

32:45One of the first things I like to do in that particular situation is okay, so who is actually using that?

32:51Who is using not only that feature, but how is that attribute being leveraged?

32:55Is it being leveraged to produce some product, like I said, whether that's a Web service...

33:01...or something in a hard-copy form, or some other business purpose?

33:05If you vet through that data and 75 percent of what a customer or an organization thinks...

33:13...they want to capture doesn’t have an intended use on the back end of it...

33:18...then you might want to rethink your data strategy.

33:20Because there's cost in designing it, there's cost in storing it, and there's certainly cost in maintaining it.

33:28Now that doesn't mean you're not looking to the future.

33:30There may be some things you want to capture for the future, you see it on the horizon.

33:35All I'm saying is, in a lot of cases we go in, especially with technology refreshes, "We've always captured this."

33:43But when we do a review of the database...

33:45You never use it.

33:46...75 percent of it is empty.

33:48So it's like well, why continue to model something...

33:49...that you're not going to truly maintain and support moving in the future?

33:56Maybe there's a reason, but at least ask the question and make sure it has a real, intended use.

34:01Yep.

34:04Yeah, sorry?

34:07Yes?

34:08[Inaudible audience question] Yes. [Inaudible audience question, continued]

34:25Okay, okay.

34:26So the question or the comment was about this seems like a very standard waterfall process...

34:31...which is, you do a task, you end, you go to another task, you end, and you drop down...

34:36...and you get bigger and bigger as you go along, as opposed to the agile method.

34:40An agile method to the programmer has a very different context meaning.

34:45But agile is small, incremental, fast, fast turnaround.

34:49I think a lot of the things that we talk about can be, we do a lot of agile development.

34:54I think in this Internet-focused, web-based systems that we're building more...

35:02...waterfall doesn't really work very well.

35:04You know, on large enterprise systems, yes, you need to understand the vision...

35:08...you need to understand the requirements.

35:10But it's very difficult to spend, and probably not going to be very successful...

35:15...if you spend a year gathering your requirements.

35:17Because at the end of the year, people have left, things have changed, and it's moved on.

35:22So I don't want to give the impression that it should be waterfall.

35:26It should be very focused, we've done requirements gathering in a day for some systems.

35:31Not enterprise systems; usually that's several weeks of work.

35:34But I'm not talking about six months or a year-plus of requirements gathering.

35:39And we can talk a little bit about that later on in some of the other activities.

35:43So bringing this together, I like this chart because it shows a couple of things.

35:49The customer requirement might be this one-line list of...

35:53...I want to be able to search for images using a point buffer.

35:56In going through that, you might break that out and make it more.

36:02They actually want to be able to draw a buffer, I want to be able to select a radius...

36:05...so it's actually a much more detailed set of requirements.

36:08But a long laundry list of requirements is not a good system.

36:14I guarantee you will be failing as building a good system...

36:17...if you just have a long laundry list of requirements.

36:19That's why as a vendor when I see proposals come out that we're trying to bid on a system...

36:25...and I turn to the requirements section, and it's 40 pages of one liners about the system must do this...

36:32...the system must do that, I just go Arrrgh, because it doesn't show the business process or...

36:39...we use the term use case, which doesn't say, I want these business requirements in this workflow...

36:49...of how they string all these together.

36:51So it's important that you don't end the requirements process here with a long laundry list of requirements.

36:57You need to make sure that these artifacts like conceptual business process modeling...

37:03...use case analysis, which is stringing them together, and the domain model...

37:07...which your programmer needs to take a look at all the objects that need to be developed...

37:12...these are critical artifacts that come out of the requirements process.

37:16So it's really, really important that you don't just stop at a long laundry list.

37:23Because your idea as an end user of how they might string together...

37:28...needs to get communicated to people who build it.

37:32The other key thing about requirements is...

37:37Did I miss a slide?

37:41Yeah, I think I missed this one.

37:44Requirements should be what, not how.

37:48So for example, I want to make a map with ArcMap...

37:54...is not a requirement; it's a solution to a requirement, okay?

37:58So the requirement is about what the map is...

38:01...so it should be about what is its extent and what the users can do with the map...

38:08...turn layers on and off, what things can they customize?

38:12Using...we call them being unambiguous.

38:16So they also should be technology free.

38:19So a business requirement should not really have a lot of Esri product names all the way through it.

38:24That happens later when you get the use cases...

38:28...that you say my solution to fulfilling that requirement is the Image Analysis extension...

38:33...or using JTX to do workflow.

38:39It's important that they map back.

38:41So one of the critical things that you really want as you get this long laundry list is...

38:45...you really want to make sure that you don't forget them and you don't lose them.

38:49And you know, this takes a lot of work, and it takes overhead...

38:53...and it takes someone who is very detail oriented.

38:58How you gather your requirements, how you update your requirements...

39:00...and how you keep the requirements is really going to be your driving success for your project.

39:07So again, just jumping, these are the three artifacts that are critical to come out of the requirements-gathering process.

39:13And again, use cases can be a Word document.

39:16And there's templates up on the Esri site about what a good use case template looks like.

39:21There are some really good recommendations on books.

39:23Use case is not a GIS term, it's a standard project management term about how people model their workflow.

39:32But these are really critical artifacts. And you need to also remember, these are living documents. These will change.

39:39So you need to make sure you go back over and over again to them as you go through your spirals...

39:45...and you do things in incremental ways saying, This is the workflow I'm working on for the first spiral.

39:51And then when you finish it, go back and make sure that you've tested against it...

39:54...and that you've checked it off and that you've moved on to the next one.

40:00Before I go to the next one, any other comments on requirements?

40:03It is one of the most critical pieces of a successful project.

40:06Yes?

40:07[Audience question] These requirements that you are ________ in doing the project, after the project has started.

40:16But before that, in the proposal phase, you need to have some requirements, the laundry list of requirements...

40:24...sometimes you think it’s better if we deal with the least [inaudible] before the project start.

40:30So is there a simple way to _______ expert in the proposal phase?

40:39From an Esri experience, when we're bidding on large enterprise projects...

40:44...we will try and do two things to minimize risk.

40:47We'll either try and break it up into, Is there a way we can get our arm around...

40:51...the requirements-gathering effort and bid it before we bid anything else...

40:56...so that we isolate the risk?

40:58So, bid that firm fixed price and figure that out...

41:02...and then say we'll give you a ROM but it's going to change based on what we do in the requirements.

41:06Or the second piece, if you can't do that, if you have to put something out there...

41:10...on the RFP is to say, Here's my long laundry list of requirements.

41:15As a vendor we often go back and say, our assumptions are these are the four use cases we're going to need to build...

41:22...and we might need to have a little bit of disagreement, but we built our assumptions...

41:27...on this long laundry list and 12 use cases, and we think those use cases are x, y, and z.

41:33And that limits your exposure if the client comes back and says, Well actually, no...

41:39...it's 50 use cases, or it's a much bigger system, you've got a way to kind of manage that risk.

41:49Okay, so managing change.

41:53You know, one of the things that we're seeing over and over is that, you know, people freak out about change.

42:04It's going to happen and you'd better have a plan for it.

42:07And so what we try and do is, your staffing's going to change, your resources are going to change...

42:13...the requirements are going to change.

42:14You're going to get a new secretary in your agency who all of a sudden...

42:17...wants to go down this path rather than some other path.

42:20And it doesn't mean that you have to...

42:24...we often use the word whatever paralysis, so whether it's either requirements paralysis...

42:31...or management paralysis, you don't want to get stuck in change paralysis.

42:36So particularly in this very Internet-focused world where things can happen so fast, you know, you can get updates up there.

42:45You can get a server of ArcGIS up on Amazon in half an hour.

42:51You know, before you had to engage the IT department and do all these things.

42:56There's an expectation of change, and each agency has its own vibe about how that is managed.

43:04In some agencies, it's quite authoritarian.

43:06You know, there is a change control board who has to certify everything that happens once it's in production.

43:12Some are much more loose.

43:15But I think it's really important that you identify it and have a plan to work through it.

43:21Every agency and division we've worked with have been different.

43:25There's not a really great way and a plan to put in place, but in your project management communications...

43:32...this is really important to understand. And usually change has impacts.

43:38And it usually has impacts on three things - the scope, the budget, and the time.

43:43And it's really important that you, as end users, and your project management say...

43:49...Okay, we can support this but this is what it's going to do to the project.

43:54It's going to make me six months late, I'm going to need two more people...

43:59...or we have to give up something on the scope.

44:01And that balancing act is what change is all about. And that's difficult.

44:07So it can get a little bit ugly but, again, it's going back to your stakeholders and your priority.

44:14If all of a sudden they've moved meetings up and they want to demo something early...

44:18...is there a way that you can figure to put in a prototype based on what you've built to help support...

44:23...and keep that win strategy moving forward?

44:29It's also important to think about not just change but risks. And risks have very different flavors.

44:35It's...you know, you've got staff risks. If you've got one DBA who knows the inside structure...

44:43...and trust me, programmers and DBAs don't like writing things down, and they haven't documented the schema...

44:49...and they move to San Francisco, that's a risk.

44:54So you know, documentation is really, really important and you have to enforce it in the team.

45:01We have a lot of code control that we put in on our enterprise systems so that they have to check in code a lot.

45:10So that when they get their laptop stolen, which they took home and left in the café...

45:16...that they don't have all the source code sitting on it, which happened once on a project.

45:22But it's thinking about, What am I doing for sourcing? What am I doing about my staffing needs?

45:30The other big one is budget.

45:32I mean, everyone's getting hit left, right, and center with budget cuts.

45:35It's important to try and figure out if you're going to be hit with those types of things, what is your reaction going to be?

45:42How do you do more with less is the themes that happen over and over.

45:48And sometimes you could do more by going offshore to do programming and getting cheaper resources.

45:54Doesn't always work. Sometimes you can't do it for security reasons.

45:57You might change your scope, you might break things down into smaller increments...

46:01...and say, well, you know, we planned to do three deliveries over the year.

46:05We're actually going to do smaller ones and use less resources.

46:10Okay.

46:11And I think on that one in particular, you know, consider...put the right focus on the right risk.

46:19So in some cases, I've seen where maybe data is going to be shared out on a web-based application...

46:28...a web-based system, but that data is not very dynamic.

46:32Maybe it changes every month, every couple months, or whatever the case may be.

46:37However, we get engaged and there's a nightly backup cycle for the data.

46:45And you've got to kind of ask yourself the question, Well, if the data is only changing once a month...

46:51...why are we backing up the same data every night?

46:55You know, so there may be other strategies to mitigate the risk.

46:59Whereas, of course, other systems that are highly transactional, that's where you really want to focus on...

47:05...on making sure you've got that data backed up and you're dealing with that transactional change over time.

47:10So risk management, identifying and monitoring risk...

47:14...can really lead people to kind of freeze up, seize up, have the paralysis.

47:21Focus on, you know, don't think that one size fits all when it comes to mitigating that risk.

47:26Understand what you're doing with your data, with your system, and what makes the most sense.

47:31Okay.

47:32I'm going to turn this mike over and we'll chat for a while.

47:38Questions or comments on anything we've talked about so far? Yeah?

47:44[Audience question] You made a reference to nonfunctional requirements, and I’m not real clear what the distinction...

47:51...between [inaudible] very specific data requirement and business process is. So what would fall into the nonfunctional planning...

47:59A lot of the things you see under External there - hardware, software.

48:02So if you're in an agency...

48:05[Audience question] What was the question?

48:06Sorry, the question was, I didn't understand the concept of nonfunctional requirements...

48:11...or nonfunctional meetings and who might be in there.

48:14Mostly it's to do with things in your agency that are about hardware preferences...

48:19...software preferences, security needs, network bandwidth, data preferences...

48:26...whether an agency that’s an Oracle agency or a SQL Server, or some other...

48:34...what are the things that the end users really don’t have any conception about, or it's not in the business process.

48:40So, we're a Linux shop, we can do Flex, we can't do Flex, we're a Java shop, we're a .NET shop.

48:47It's all those requirements.

48:48So what are the things that help you define that box of a system?

48:53And sometimes, we go into meetings, in these nonfunctional meetings...

48:58...and the IT people look and say, whatever you want to do.

49:01And so...

49:02I like those.

49:03So you know, I put up...I say, Okay, we want to run on Macs, I mean we don't even do Macs.

49:14We want to put Macs and we want to do some free, open source database that's a personal...

49:22...like a personal geodatabase and we want to run on everyone's desktop and we don't want it to be web.

49:29And I give them a crazy scenario and they look at me and go, Well, you can't do that!

49:33And I say, Well, so what can we do?

49:36So it's getting to that conversation point of, What are the things that you know about...

49:40...that are going to be the restrictions in your project?

49:50I think someone had asked a question about being agile or using an iterative approach...

49:56...and that's a perfect lead-in to this next slide.

49:58We’ve kind of touched on it with several of the slides that we've gone over...

50:03...but I think one of the things that we try to focus on is using a phased implementation approach...

50:10...or trying to be as agile and iterative as possible.

50:15There are...now, there's a lot of misconceptions around agile or an iterative approach...

50:20...that there are no requirement session or there's no documentation.

50:25That's not what we're discussing here.

50:28What I'm ultimately describing here is breaking that project up into multiple phases.

50:32And the significance of that is, I mean, think through some of the bullet points...

50:36...or the slides that we've talked about thus far.

50:38You need to engage your stakeholders.

50:40You need to understand what success is and be able to address...

50:45...that changing definition of success over the life of the project.

50:50You need to deal with new technology that you maybe never have dealt with before.

50:55You have ever-changing and ever-released COTS technology that you may want to leverage.

51:01Using a phase-based approach will allow you to begin to address some of those things.

51:08One of the things that Gerry focused on or spoke to was...

51:12...be prepared for change because you're going to be dealing with it.

51:15That's just the reality of today's project management.

51:19And especially if a project spans a long period of time.

51:22If you go in with an iterative or an agile approach to start with...

51:27...you're already kind of setting the groundwork that things are going to change.

51:31There is no massive, big, up-front requirements focus for 6 and 12 months.

51:37And that's also...I want to make sure I'm clear here when I talk about manageable phases and spirals...

51:43...I don't mean we do requirements gathering for six months, that's phase one...

51:47...we do design for six months, that's phase two.

51:50That's not what I'm saying.

51:52Now, I do believe you need to establish your high-level business requirements...

51:56...and certainly your requirements determination for the project up front.

52:01However, you expand on those as time goes through the multiple phases.

52:06You're going to want to make sure to look at a given use case.

52:09And for that given use case, make sure that you're addressing it in your phase, your spiral, your iteration.

52:17Now, when we've done this in the past, or when I've done this on other projects...

52:21...people say, well, now, wait a minute, so you're telling me I'm going to do a use case...

52:27...a particular use case in phase one, and that's it.

52:30Now in phase two I'm going to do some other use case?

52:33That's also not what I'm saying.

52:36You identify some key use cases up front that you want to model...

52:40...you want to design and develop and address in phase one.

52:43And more importantly, get user validation as a part of that process.

52:48But that doesn't mean you're not touching that use case or that workflow...

52:53...or that business process later in a subsequent phase.

52:56So it may be that you identified 10 of the key steps...

53:00...in a particular workflow or business process within your solution.

53:05However, you address some additional steps or hand-off points in subsequent phases.

53:12The key here is breaking it up into something that's manageable.

53:16And not only from a technology perspective.

53:18A lot of people like to look at it, especially if you're on the development side of the house, you're like, well...

53:22...I've got to build this component, and then I'm going to build this component...

53:24...and then you kind of work through your project in that way.

53:29Don't forget about your stakeholders.

53:32You've got somebody out there that's giving you money to support that particular project.

53:37They have funded something where there's a key business driver that you as a project manager...

53:42...sold to the organization and said, Hey, give me this investment and I'll make it work for you.

53:48I suggest, if you can, to show some early benefit for that investment.

53:54That's going to pay off in the long run when you have to go to them later and say...

53:59...Well, I've seen some new technology, or I've worked with some other user group...

54:03...and I think we can go even further on our benefits.

54:06Look at where you can get some bang for the buck early in the project.

54:10And doing a phase-based approach will allow you to do that.

54:15When you set up your project plan, or however you're going to communicate...

54:20...your project task, make sure you're addressing that in there as well.

54:26I've dealt on agile projects or an iterative-type project where they look at...

54:33...they try to map everything out for all six phases.

54:36So they say okay, we're multiphase, we're six phases.

54:40But they may spend an incredible amount of time designing what's going to come in phase five.

54:46So it doesn't make sense to do that, because users are going to learn what the technology does.

54:53We, as the COTS experts, or the integrator, or the developers or whatever...

54:58...they're going to learn from the business.

55:00It doesn't mean you're not looking on the horizon of what's coming.

55:03You always need to be aware of that, but focus on what's immediately required...

55:07...for that first phase, address it, and you start working on the next phase.

55:13The other comment, just on that one, is please don't get into MS Project paralysis.

55:19So you know, a 500-page project plan in Microsoft Project is unmanageable.

55:29I don't care how big your system is or your project is.

55:32You need to be practical; otherwise, you're going to have to have a team of people...

55:35...dedicated just to keep that project plan up-to-date.

55:38So it's really important to kind of have some real...you know, be practical about it.

55:46That doesn't mean you break it down into what you need to break it down into...

55:49...but you know, managing the MS Project tasks at you know, four-hour, eight-hour increments...

56:02...is just going to be unmanageable.

56:04So you really need to kind of...

56:06On different projects it's different, and it really relates to the spiral and the level of detail that you've got.

56:12But don't get stuck in MS Project paralysis because it can be something you never get out of.

56:22And that kind of carries to my next...

56:25...from a communication standpoint, we talked a little bit about, you know, multiphase and the changes...

56:31...or being prepared to deal with change in your methodology as you start your project.

56:35Promoting communication. You would think, with all the ways of communication and the devices...

56:45...and those types of things that we have today, you would think that communication would be easier today.

56:51And in some cases it is. But what I'm talking about is effective communication.

56:55I'm talking about purposeful communication.

56:59Make sure, as a project manager, that you are actually creating a communication plan.

57:04And the significance of this is, it continues to tie back to (a) the project plan; the project plan is important.

57:11It does tie back to your stakeholders. When do you need to notify them?

57:14When should you notify them? How do you keep them in the loop?

57:18How do you engage with a group that may be delivering resources...

57:22...to your organization and supporting your organization?

57:26From that, make sure you're identifying what are those artifacts going to be, how timely does that need to be?

57:33We get into cases where we're working with different organizations, or even internally...

57:39...where somebody wants to have a status meeting every other day.

57:44And that's fine if it's five minutes and there’s some critical issue going on...

57:49...that you need to keep that constant pulse on it.

57:52But the big concern that I think I always have is, I really don't want a lot...

57:57...of people sitting in a conference room. I want them knocking the project out. I need them focused on that.

58:03So I may require a different level of communication from a developer or somebody...

58:08...who is engaged day-to-day in work items than I may from a team lead.

58:15These are things I'm sure all of you all are employing today, but make it very purposeful.

58:20And sometimes you'll find out that whoa, wait a minute, I'm leaving some key stakeholder out.

58:25I'm forgetting to communicate to them.

58:28And that can begin to expose a potential risk that you need to deal with.

58:32Remember, though, that these are just artifacts. These are just tools.

58:38In other words, the project plan, a risk log, action item register, those types of things, those are just tools.

58:48And the tools will never deliver a successful project.

58:52The people deliver the successful project.

58:55And the way you do that is via the communication.

58:58So don't get too wrapped up in the project plan analysis paralysis and those types of things.

59:04However, be very purposeful in your communication.

59:12I don't know if anybody has been in this situation. I've been in similar situations.

59:19It seems...you may think it's kind of funny that, me being from Esri...

59:26...and being here at this conference that I start off something that says...

59:30...don't get enamored with the technology.

59:33Obviously, a large portion is the technology. It is important that you're focusing on that.

59:40However, don't let it distract you from what you're trying to deliver.

59:44I think Gerry brought up at the very beginning, you know...

59:46...maybe you've got a process to capture point data, or whatever the case may be.

59:52You probably don't want to spend 90 percent of your budget on an imagery solution.

59:56Maybe you do. I mean...

59:58But the point is, focus on what makes sense for your business goals and what you're trying to accomplish.

1:00:04We've all been...

1:00:06You know, like I said before, for years I was a customer.

1:00:09And I got distracted by the shiny object just like everybody else...

1:00:15...where I would come into one of these conferences...

1:00:17...and I would see a particular function or a tool and say, I gotta have that.

1:00:22I gotta have that, I think that's great, and I might have even put focus in on that...

1:00:27...and driven a project team to get that accomplished.

1:00:29And at the end of the day, it's like, man, that is great, but nobody's using it.

1:00:33It's not supporting any business function that I have promised to my sponsor. Be careful of that.

1:00:41I think the key thing is, you know, don't build or deliver a sports car if you need a truck.

1:00:46You have seen a ton of technology yesterday...

1:00:49...you'll see it as you walk through the exhibit floor, and you see the functionality...

1:00:53...it doesn't mean that you may not queue that up as a potential thing you want to target for a future phase.

1:01:00However, remember, somebody has provided you funding potentially to deliver a solution.

1:01:07And you don't want to allow you getting enamored with the technology to distract from that.

1:01:16Anything else?

1:01:17Yeah, the only thing I would add would be on the other hand, if you see something...

1:01:24...that saves you from writing custom code by buying a piece of technology or a solution, do it!

1:01:32The worst thing you want is custom code.

1:01:35And you know, as a consulting practice, I probably shouldn't be saying that because we live on custom code.

1:01:39But, COTS is so critical.

1:01:43And if you've got tools out there and you see a piece of technology that will revolutionize...

1:01:50...how you do a piece of your business, it's incumbent on you to look at it...

1:01:55...and really challenge why you're doing it the way it is.

1:01:58Because if you can buy a piece of technology or a solution that is going to get updated...

1:02:05...by someone else and kept up-to-date in all the versions of Linux or .NET what you build...

1:02:10...you don't want to write a GOTS or a custom piece of software.

1:02:13So that's the only kind of balancing act you have there is, you know, there are solutions out there...

1:02:18...that will make your life easier, but it has to support your business.

1:02:22Well, and to further elaborate on that point, by implementing COTS...

1:02:28...obviously you're going to get functionality that comes in that COTS package...

1:02:32...that may not be something that's directly tied to your business goals or your drivers, but it is there.

1:02:40So also, I think that's a key point, make sure you're focused on that as well that...

1:02:44...hey, I don't have to go off and spend a lot of time, energy and effort on designing something...

1:02:49...out that I know is coming to me anyway as a part of that COTS release.

1:02:56Ten minutes.

1:02:58Okay. Talked a little bit about engaging the IT department.

1:03:02They are a key stakeholder, especially when it comes to an enterprise...

1:03:07...I mean, most of the time they are a key stakeholder regardless...

1:03:11...but especially when you're talking about a large enterprise system.

1:03:16Engage with them, and engage with them early, and keep them involved.

1:03:23I think Gerry touched on a little bit earlier...

1:03:25...you don't want to go through the process of designing out a particular function...

1:03:30...or a solution, then it's time to deploy it into your network and you're ready to really roll this out...

1:03:36...and have it public facing, and IT says, Are you crazy?

1:03:41You know, we're not doing that, we're not going to support that.

1:03:44So engage them early so you make sure you're playing within your boundaries.

1:03:50And I always like to make sure to also say...

1:03:53...and make sure you're also pushing your boundaries.

1:03:56In some cases, we go in and we get an IT standards and policy document...

1:04:02...and somebody blows the dust...

1:04:04That's two inches thick.

1:04:06And they hand that document, and they say, Okay, here's what you need to play within.

1:04:10And you end up looking at it and yeah, it looks like maybe it's about 10 years old...

1:04:16...and it doesn't address a lot of the new technology...

1:04:18...and the new things that businesses want to accomplish.

1:04:21So what you want to make sure you do is identify those early.

1:04:24And I learned two things today.

1:04:27One thing, I'm not supposed to be judgmental.

1:04:30And I'm supposed to be diplomatic, I'm not used to that.

1:04:35But one of the things, make sure you're engaging the IT so you can challenge back...

1:04:40...and you can say, Hey, things have changed, we need to do this.

1:04:44And you can get your stakeholder that's really driving a business need...

1:04:48...and your IT department together and really kind of hash it out.

1:04:51And maybe you can change a policy.

1:04:53Maybe you can have the organization understand that with this technology things are a little bit different...

1:04:59...or there are some new things that can be accomplished.

1:05:01But if you don't address that early, that's a difficult battle to have.

1:05:06When you're done, you've got your solution kind of sitting in a can and you're ready to deploy.

1:05:11Understand hardware and network impacts.

1:05:15So you know, one thing that's a little bit different about GIS systems...

1:05:21...especially if you're looking into a production management type of system...

1:05:25...where you're capturing new data or modifying data, a lot of vector data, you need to think through...

1:05:31...well, where is that data, how is it going to be distributed across the network, the enterprise network.

1:05:36How is the data going to be transmitted back and forth?

1:05:40Understand what the infrastructure you're deploying into looks like.

1:05:45The nice thing about some of the COTS technology that's out there today...

1:05:49...is there are several different ways to accomplish the same thing.

1:05:53So it may be a case of yes, a heavy versioning model works just fine...

1:05:58...or maybe you need to have disconnected replication in place.

1:06:02So understand, sometimes in the nonfunctional requirement...

1:06:06...the infrastructure can begin to affect your solution and will affect your solution.

1:06:12But I also, I also want to emphasize is plan to educate and train the staff, obviously.

1:06:19But don't stop with the end users. Understand that the IT staff also needs to be trained.

1:06:27In a lot of cases, people would not bring in somebody who had never used Oracle to be an Oracle DBA.

1:06:36Why would you bring in somebody who had no skill sets using the COTS technology...

1:06:42...you're deploying or the solution you’re deploying?

1:06:44Make sure that they have that skill set, make sure that's part of your plan and that's part of the training plan.

1:06:55We run into this constantly.

1:06:59Make sure...I mean, that can be a significant risk for you, because a lot of us maybe have seen the technology...

1:07:05...used the technology maybe for six months, we've been working with it...

1:07:10...and we just think it's second nature to us.

1:07:13Whereas, somebody in the IT staff who is highly qualified at Oracle...

1:07:18...database administration or a Windows system administrator, whatever the case may be.

1:07:22We just assume, well, you should know this technology. And that's unfair.

1:07:26So make it part of your training plan.

1:07:33Keep it simple. Keeping it simple doesn't mean you eliminate good business practice around project management.

1:07:41It doesn't mean you eliminate requirements...

1:07:43...it doesn’t mean you eliminate design or you don't do documentation.

1:07:47That's not what I'm saying.

1:07:49All I'm saying is, identify the right business rhythms that work for your project.

1:07:54You know, if you're not building a fighter jet...

1:07:58...maybe you don't need to have a fighter jet project plan that you're tasking out to your team.

1:08:04What makes sense for you?

1:08:06Design and build for that 90 percent use case.

1:08:09Make sure that if I'm getting 90 percent of my value in a particular area...

1:08:13...and that's where I've identified on those clear business goals...

1:08:17...make sure you're investing 90 percent of your focus there.

1:08:20You know, I've seen a lot of times where people end up spending so much time...

1:08:25...energy, and effort trying to solve 10 percent of the business need.

1:08:30And it gets out of whack. Next thing you know project's overrun, stakeholders aren't happy.

1:08:35So make sure you're aligning your business rhythms...

1:08:38...the way you're managing your project, with the value that you're delivering to your stakeholders.

1:08:44And I think this gets back to the COTS discussion we just had. Do you need to customize or configure?

1:08:50You probably don't need to spend significant amount of time describing and designing how to do zoom in.

1:08:58Zoom in existing COTS, don't document that.

1:09:02I mean, identify that you need it for your use case, but you know, in a lot of cases...

1:09:08...what the project manager should be focused on is...

1:09:12...you're trying to deliver a business solution to a business problem.

1:09:17You're not trying to engineer a new software module.

1:09:21In some cases maybe you are, if you're a business partner or something to that effect.

1:09:25But just make sure to bash it against reality. What are you really trying to accomplish here?

1:09:31And it kind of goes without saying, another cliché to throw at everybody, don't reinvent the wheel. Leverage what you can.

1:09:37By doing that, you know, I mean, I think Gerry touched on it.

1:09:40If we see project plans that are thousands and thousands of tasks...

1:09:46...big up-front requirement sessions, big up-front design sessions, we get very, very concerned...

1:09:53...of what the long-term viability of that project's going to be.

1:09:57So just keep it simple, avoid the complexity...

1:10:01...and I think that's probably the last key component, if you will.

1:10:09How are we doing on time?

1:10:11Five minutes.

1:10:12Okay.

1:10:14So to recap, what we put up before hopefully...

1:10:17Question?

1:10:18[Inaudible audience question]

1:10:38Well, and I may have used a...let me make sure I'm clear.

1:10:43Obviously, if you have...if you've defined the scope of your project being "X"...

1:10:48...and it's measured in, you know, here's 100 percent of the project...

1:10:52...all I'm saying is, make sure that the amount of energy and effort that you're putting in...

1:10:59...at the task level matches what the business value or the business return is going to be.

1:11:05And I think what I've seen in the past, I'm not saying it's a silver bullet to everything certainly...

1:11:11...but in most cases if you can articulate, if you can communicate that you do understand...

1:11:18...we're investing 2,000 man-hours into something that's going to bring very little business return...

1:11:27...if the stakeholder is providing funding, in most cases they'll hear that.

1:11:32I'm not saying everybody's reasonable certainly.

1:11:35But just making sure to align your effort, your resource, and your investment...

1:11:39...with where you're going to get the biggest bang for the buck.

1:11:46I think there's a couple of...

1:11:50You’ve got a recap, you've got the slides...

1:11:52Can you put the other ones on?

1:11:53There's a couple that will come up with some additional resources.

1:11:59The Professional Services, the Support Center on esri.com has a lot of templates...

1:12:06...for almost every document you would ever want to create in a project.

1:12:10It's got some very good use case stories there about how people have done things.

1:12:15There's an island down in the Esri Showcase called the Professional Services Island...

1:12:20...it might also say Project Center, I don't know what they've called it this year.

1:12:23But colleagues like both Glen and I will be there at some stage.

1:12:27Other colleagues and peers of ours will be there, so if you have questions about requirements gathering...

1:12:33...or nonfunctional requirements or anything we've talked about, please stop by there...

1:12:39...and get some of those answers, and we can certainly point you in the right way.

1:12:43I think there's a second one?

1:12:45Most of these additional books are very software oriented, that you could use to run any project.

1:12:54So the Rosenberg Agile one...

1:12:58...Rosenberg is one we use an awful lot on the UML side of things.

1:13:03And the project requirements one on the Karl Wiegers, we use an awful lot.

1:13:06But there's an awful lot within your agencies you might already have best practices of how to do these.

1:13:12And you can really take a lot of standard software development books...

1:13:17...and project management books to really learn from.

1:13:23We're probably out of time.

1:13:25The next thing comes in here at noon I think.

1:13:27There's a SIG coming in here, the JTX SIG.

1:13:30The general strategy is people can go grab lunches in different places.

1:13:33There's lots of different SIG user groups happening in many of these rooms here.

1:13:40If you've got questions, we're going to be here for the next 10, 15 minutes, or come down and see us on the Project Center isle. Thank you.

1:13:46Thank you.

1:13:48Fill out the survey.