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... 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... 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... 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: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... 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... 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... 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... 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...'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... 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... 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... 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 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' 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... 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...'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... 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...'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...'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... 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... communicate how money is getting distributed for your agency for targeted programs...'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... 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... if they're on a mobile device out in the field in their workflow... 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... 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... 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... have any external data web interfaces.

26:48So they will be mutually exclusive.

26:50And that's when your stakeholders become really important... 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...'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... 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... 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..., 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... 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:04Yeah, sorry?


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... 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... 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... not a requirement; it's a solution to a requirement, okay?

37:58So the requirement is about what the map is... 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... 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: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... 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...'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... 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' 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: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: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... 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... 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, 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... 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...'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... 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... 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 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... 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... 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 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...'ll see it as you walk through the exhibit floor, and you see the functionality... 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... 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... someone else and kept up-to-date in all the versions of Linux or .NET what you build... 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... 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... 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...'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... 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..., 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...'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:14So to recap, what we put up before hopefully...


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... 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 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... 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.

Copyright 2014 Esri
Auto Scroll (on)Enable or disable the automatic scrolling of the transcript text when the video is playing. You can save this option if you login

10 Things to Know about Managing GIS Projects

Esri Senior Project Managers will share best practices for managing GIS projects.

  • Recorded: Jul 1st, 2010
  • Runtime: 1:13:50
  • Views: 105328
  • Published: Aug 25th, 2010
  • Night Mode (Off)Automatically dim the web site while the video is playing. A few seconds after you start watching the video and stop moving your mouse, your screen will dim. You can auto save this option if you login.
  • HTML5 Video (Off) Play videos using HTML5 Video instead of flash. A modern web browser is required to view videos using HTML5.
Download VideoDownload this video to your computer.
<Embed>Customize the colors and use the HTML code to include this video on your own website
Start From:
Player Color:

Right-click on these links to download and save this video.


Be the first to post a comment
To post a comment, you'll need to login.
If you don't have an Esri Global Login ID, please register here.