MMP3: Managing Projects in Web Development

Speaker: ...an awful lot of material to cover in a very short period of time. I have been doing project management for years and didn't realize it. And I have been screwing it up for years and couldn't figure out why. And then when I finished my master's degree in IT Management, the last four classes where in-depth studies of project management.

I'm like, "Oh, I get it now." I see what I was doing wrong all these years and so I started applying the principles that I learned in that degree and I started having extreme success very quickly. So I want to share what I have learned so far and hopefully, we can spread the knowledge and spread the fun.

So first of all, we got to talk about what's going on. It's a headache out there. There is nothing you can do about it. You're trying to organize everything that is being thrown at you last minute and nobody plans in advance. They always sort of last minute, "Hey, when do you need this?" "Yesterday." "Thank you. I appreciate that."

If you do not find a way to organize this material, it will override your life, building stress. I mean look at this poor guy. Trying to manage everything and everything is different. Everything has its own priority. The biggest thing is we're looking for that efficiency. We're looking for nimbleness. We're looking for a way to try to organize this thing.

And some of this requires a little bit of backbone and we'll talk about that as we go through this thing. So we need to figure out in the beginning kind of the classical style, what the heck is project management in the first place?

Project management is not for daily or repetitive tasks. It's for one-time use only. So if it's a process that I have like update the news everyday, I might have a project to organize and get it ready. But after that, it's a process. It's activated as running. So that's not a project management.

A project is actually something that's a one-time use, getting something ready and running. It usually has one specific person who's in charge. They are the key stakeholder or the sponsor of the actual project. You got to identify that. In years past, I made the mistake of not figuring out who the heck that person was until it's too late.

So you walk through the project and it kind of goes in a circle here. So you start a new plan and you keep working your way around through the following support. As you actually define your project, you can start to develop it.

You organize. You create the special services. You try to get that one-time unique result out of whatever it is you are building, whether it's a full web application or redesign, whatever. It doesn't matter.

And the biggest thing is the more time you spend on the organization and communication, the less stress you will have overall, because there will be a plan to the approach.

So let me turn this sideways. I hate hiding behind the podium. Close enough. So here.

What's the biggest problem in the web? What I learned yesterday is not necessarily true tomorrow. It is shifting. It's a moving target, "There's a new browser release." "Oh, great." "That no longer works today." "Thank you."

We have all kinds of critical needs that are institutions. I would love to work for a private company. Their focus is really defined. My goal is to develop or deliver X product or service or whatever. We have the unique opportunity of saying, "OK, we have to be everything to this entire community and we don't know what they want and they can't communicate effectively." Congratulations, welcome to the nightmare.

You have to understand that at the same time, marketing says they're the most important thing. At the same time, there are information technology needs as well as the information needs you try to develop to all of the people in the functional areas.

You are integrating more mobile applications now. Their projects are just spiraling out of control. That is our biggest headache and we've got to get this fixed. I realize there is an awful lot of text but I want to read to you a couple of things.

This is a Scenario A: Loss of Control. A new hybrid department in the campus is offering courses to a variety of students in outlying areas, enabling the students to take this class pretty much virtually.

The department chair requests a meeting to discuss their website. When they arrive at the meeting, you discovered they have hired an outside vendor to build the website which you are supposed to implement on the server.

The department chair signed the contract however, bypassing all purchasing operations requiring the university mandate that all website development be done in-house, AKA "They won't pay for it."

So the vendor's frustrated that nobody has paid them. The department chair is mad that the site isn't online yet. You are just frustrated that they showed up at your door. Anybody had anything like this at all? OK, all right.

Scenario 2, we have a minor upgrade issue. When anybody says minor upgrade, let me determine the use of the word "minor." Nothing is minor except the people digging earth.

You build a web application to help file Travel Expense Reimbursement applications, the TER claim for the University Business Office. Outside of the basic annual maintenance of updating the general mileage and high cost city limits, there has been no real change in the last six years.

There's a few financial systems being rolled out which require a Person ID to be added to the Travel Expense Report therefore can tie it in to Tax Reports at the end of the year, blah-blah-blah.

The problem is no one seems to know what their Person ID is. But they will have a combined table of the ID that you people do know, the Employee ID along with the Person ID but that will be available sometime in the spring, but the new requirements take effect yesterday.

OK, cool, yeah. That's good one. I'm sure that sounds familiar for some of you.

This is a fun one, the new front door. The homepage for the university has been online and functional for almost two years. Apparently that's old anymore. The president of the university retired six months ago and the provost, who is retiring in eight months, was appointed the interim president for the remaining eight-month search for the new president.

Knowing, from talking to the talking to web person for the last eight years, whenever you get a new president, within six months they will mandate a new homepage. I didn't know this. You know this.

So you are preparing your team in advance for the impending arrival. That was within two hours in one day those three projects came to my door. So OK, let me go get some coffee. What do you do? There's too much to do. I happened to be at the right time in the wrong place. So here's what we need to do.

We need to come back to project management and its origins. Let's look at it from a simple concept. Project management is managing processes and tasks. It's identifying issues and identifying specific problems. The most important part is you have to have a method of tracking that. If you don't have a method of tracking, you will be spinning your wheels forever.

You have to focus your communications and you have to manage the expectations. That last one was key for me. If I manage expectations, I can control the project. If I cannot manage expectations, I've lost all control and it drives me crazy.

You have to remember though that project management is not just scheduled tracking or being in control or a way to try to eliminate stress. It can help alleviate some things but it can't eliminate it entirely.

It's not just a tool. It's not a technical thing. And it's definitely not an option. You are doing project management, whether you realize it or not. If you don't realize it, you're probably doing it wrong. So this is kind of your epiphany moment, hopefully.

So this is more old-school style. This is general project management. I don't care if you are running the Olympics, if you are trying to build a building, or if you are trying to do anything, all projects start the same way.

The Initiate cycle: the Initiate cycle never has a dang thing to do with any of you. There's somebody else who had this brilliant idea and they come to you saying, "I need X." And this is the bickering, you go back and forth. "What do I want to do now?" "OK, well, what resources do you have for me? What's your timeframe, what's your approach?"

Insight here, this is the actual execution of the project. And then we finally finish he project. So it begins with a project plan. As soon as I have a plan in place, I can start to execute. The whole time I'm executing it though, I'm controlling.

The Control -- this entire bubble here should actually be labeled Control but this is the traditional view of project management. I'm not going to deviate. PMI might shoot me or something.

But if I control the planning process and what they are putting into it, if I can control the execution process to make sure they are following through, if I control all the expectations all the way through, I will actually have a successful project on time, on target, on budget without major headaches.

So we have step to it very carefully. There are different things you must understand. There are different processes. You have to identify those process groups: the Initiate Plan, the Execute, the Control section, and the Close.

But within that, all these knowledge areas stack in on top of that. And I didn't quite realize initially how important this overlap was and there's really no easy way to depict that. I apologize for the gluttony of lists here.

The knowledge areas are: how does it integrate? Integration within social, integration within information, integration within technology. The overall scope, managing scope -- I think they have about one class where all they talk about was scope. It was amazing. I learned about how to manage that stuff.

Your time, and time, that also associates with human resources management up here. So these kind of tie up together.

Your cost, I don't know about you but traditionally my cost is a roll of duct tape. I don't get much more budget than that, "With what you have, I need you to perform a miracle, perform for me a dancing monkey."

At the same you'd want to have quality because I don't want to have to redo this project a year from now. So when I'm doing this plan, I'm walking through all the individual stages to make sure I have everything covered. I don't want to get caught.

We talked about the human resources but it always helps to ask the sponsor, "Do you have any extra help you can lend me for some particular project?"

The communication issue is the bread and butter of project management. If you don't understand communication and how that can be your advocate, you are going to get a real eye-opener today.

Another knowledge area: you need to know the impending risks. Sometimes, that helps you determine priority. A risk is different if you can't get something done because somebody's just upset, versus you can't get something done because you can't register for classes. There is a kind of a difference.

If it's in the middle of the semester, registering for classes is not big of a deal. If it is a week before the classes starts and you need a last-minute registration, you have an issue that definitely prioritizes things for you.

And then finally, the procurement process. I don't know about you but normally, web developers never get access to the procurement chain. Usually, you are asking, "Can you please buy this for me?"

I'm currently saddled with a project where they totally screwed up the procurement plan. We'll talk about that later. And everything is backwards. It is actually delaying the project almost a year. It is really frustrating.

Let's think about this in concepts of food because that's what we do when we get together. I don't know, when four humans together, they tend to gravitate towards food in some way. Let's talk about a Thanksgiving dinner concept. So the Initiate group: what do you do when you are going to initiate Thanksgiving dinner?

Well, the first thing is you get a phone call from family or friends or whomever saying, "Congratulations! We've put you in charge of Thanksgiving this year." You're like, "Oh, crud."

OK, let's think about this. What do I need to do? So you start to prioritize. I need to breakdown the individual tasks. It helps me formalize the thought process. I'm walking through the individual components. It is the key decision that actually initiates the entire project and all the actions.

At this time, I also identify all the stakeholders. For the concept of Thanksgiving dinner, who is invited? Who do I not want to invite?

These things are very important and this is very true for projects. There are people I want on the table and there are people I'm like, "No, you are not allowed. I've dealt with you once before. You're just a total distraction to this entire flow."You need to know those things and you got to be forceful about it.

The important part of the Initiate is to identify what the heck you are doing. The more clearly you can define what you are doing, the more successful your project will be. So as we walk into this, we go into the next stage, the Planning stage.

Inside planning, this one, I'm sorry to say, I have never ever heard of a project which is planned once and executed and there was never a re-plan phase. You are always re-planning. So you keep on going back to this stage.

You're trying to organize a scope. You're trying to organize the efforts, the objectives. You're pushing through everything to clarify. Make sure you identify all the risks, get the appropriate sequences. Find out at what point do you have a critical path.

A critical path is where you have something that has to be done. And it is by a very finite resource or a point in time. Right now, I am the current critical path in one project. Until I do something, nobody in campus can do anything else. So right now, I am the critical path in one project. So I have to expedite everything before I showed up for the conference so it can actually proceed while I'm gone. Otherwise, I'm the delay and this would be another delay week.

We need to make sure you get everything scheduled. Make sure you are keeping track of all the resources. And sometimes, resources are kind of hard to figure out especially if you don't have much of a budget or it is an area that also has no budget, then you have to be creative.

And the important part of planning is the last one: you are continually communicating. If you are not communicating effectively with everybody in your stakeholder list, at the key moments, you are going to cause problems.

We roll into the Execution phase. When you manage your execution, it's not just looking at the project list of to-do items and just going on down the line. You are actually evaluating. What's the current status of this? Am I really at the stage where I think I should be when I'm working on this project? If it's a database, that we need to hook up into a website when we're thinking of some application and we're having problems at the install. It is taking three or four days longer, that's delaying everything. So I've got to find additional resources to get that bad boy back on track.

Or go back to my stakeholders and ask for an extension on time. Or get to the networking area and see if they can provide some additional assistance: I got to do something to get that moving. So you have to learn at what point when you have to move things along.

Your team is going to be very, very important. The longer you are in an organization, the more you will understand the politics and the resources of those individual team members.

I don't treat any of my students exactly the same. Everyone has unique skills. I know what those skills are. I will leverage those skills at anytime I can. And I also know skills of everybody else on campus who has worked with me in the past.

So I also keep that in mind. And I keep doing favors for other people because I know that when I have a big project, I can call back and return those favors, say, "OK, I really need this. Can you can give four hours of your time today. We'll carve through this project. We'll get that part done. We'll keep moving but I've worked ahead on some of those things.

So that communication really comes back in to the very beginning, that Initiate phase. When you meet with your stakeholders and you accept the project and you are proceeding, the number one thing I ask them is what do you expect for communication, because some people want a daily email. I tell them, they're nuts. I shoot for weekly at most. I hate doing frequency more than daily.

The other thing I want to know is what do you expect to see in there. Sometimes, they want to hear like a percentage complete. Sometimes, they want to know what the task list is in the first place so that you can kind of give them an approximate. I completed the first five tasks or Task 1-A or whatever it is.

But if you don't find out from them what their expectation is in the communication, you will never meet it. And if it's a task on the administration's eyes that it needs to get done, when they ask them project going, they are going to respond, "I don't know. Silly web developers did not give me any information or nothing valuable, regardless of the fact that you have been communicating. So you got to find out in advance, what the heck they are expecting and then I usually provide them a mock-up, "OK, well, if I send you an email or a document that looked like this, is that going to be sufficient?

It seems like an extra step and I'm wasting a little bit more time, but if I control that expectation, they will leave me alone when I'm actually working. Then I also set up a schedule, "OK, I'll send out an email every Friday. By 3:00, I'll have it done. It will be in your Inbox," whatever the task is. But that expectation is important.

And as long as I go that effort and they are constantly communicated, I can also continually update them on resources. If I know, for example, a database is giving me issues, I can call back and say, "Hey, we're having issues here. We may need to address this."

And hopefully, the project sponsor that you have has some kind of ability or authority to give you additional resources, if necessary.

So now we move into the fun part: monitor and control. This is constantly going on. It goes on from the very beginning. You are constantly evaluating and the most important one out of this is scope. You control the scope of a project, you would at least have an opportunity to achieve success.

At the same time you are controlling scope, you are constantly trying to mitigate any potential risk. That is a challenge as well because sometimes, a risk is unknown. You don't know about an update to a machine that might have broken something. You don't necessarily know about a risk of somebody having a food allergy if you invited them over to dinner.

So I usually try to, if I'm hosting a dinner, in this case, a Thanksgiving dinner, I will send out a note, "This is what I'm thinking about having." And I ignore my sister who always says, "Hey, how come we're not having chicken nuggets." She has exotic diet.

But I need to know if I'm saying. "I'm having peanut butter pies and somebody's has a peanut allergy, I'd rather know in advance and it gives me warning. I could say, "Oh, well, I'd better have Plan B as well." It's little things like that. So that's part of your Communications section.

You are always checking for quality. I hate it when somebody develops something then releases it and when you look at the code later and you look at the resources, it's just really kind of duct taped together. It's nasty

 I don’t want to have to come back and redo a project.  If I don't have time to do it right the first time, I will never find to do it a second time. So you have got to hit it right the first time on the head.

And the administration of procurement, I don't know. How many people who have administered procurement or actually do purchasing for their area? That's what I thought. I think you're going to see a trend over the next few years where web developers are going to be brought in more into the fold of some of that RFP process. So you will probably see more of that and I'm getting beat up in the head over it now. It's kind of fun, in a sarcastic note.

The Closing, you can't close until the project's sponsor says, "Good job." Get the old "attaboy." If you're not getting that "good job" note, you're not done.  So that's why the communication all the way through, you're organizing and you're getting their expectation because when they're done, you need to get that closure from them. Until you have that, it's not completed.

The other thing is when you do that deliverable, you are going to activate whatever that new process is if there is a new process. But there is another part that I don't have in here that should be right underneath this point. When they accept it, you should have full documentation of everything at that time. More than likely, you have to have two levels of documentation.

They are going to have to present it to somebody else. You need a very high level, like one or two pages explanation what is going on, 50,000-foot level. Then you are going to need that nitty-gritty ground level just in case you need to repair the system in the future. So you got that down there.

I consider that part of the usual deliverables, but in IT projects, they usually separate that and put that as a requirement as we run through things.

So when I'm finished, I usually have a brief meeting. I go through a full debriefing. I put them in charge of whatever the project is and I say, "OK, here you go. Use it." And I don't give any instruction because quite honestly, if instruction is required, there should have been a training component in my project. So if there isn't a training component and they can't use it, the project's not done until the training component is done.

So that's another piece to it: if you set it down in front of a machine and they can't do whatever it is that it's supposed to be able to do, it's a failure until that can happen. So these are all little tidbits that I kind of picked up through the years.

And when I'm done, this is done in-house. I sit down with my team over pizza or a whole bunch of Mountain Dew and we do a recap: what worked, what didn't work, what's sucked really, really badly, who made the biggest mistake in the project, and what did we learn about it. I don't celebrate the successes. I celebrate the failures.

Because if somebody goes in, they type a piece of code and go, "Oh, crud, I just dropped the entire database. Oops." OK, well, we learned something really, really valuable there. Let's all share in that so we don't do that again. So I celebrate that point.

I say, "we all learned something," and that essentially helps me refine internal business  processes as well. So keep that in mind: Making a mistake is not a bad thing. I've been trying to re-educate my staff on that point.

I've also been trying to re-educate them that there's no way you are going to know everything you need to know to do this job. You make it up as you go along. That's most of it. This is an evolutionary science here. We are making it up as we run through.

So here's the fun part. You've got to manage the schedule, the cost and the performance at the exact same time. If you neglect one of those three legs, the other two will suffer. If I neglect performance, I am going to increase the schedule and I am going to maximize the cost. If I neglect the cost, then the performance and schedule is going to be affected. They are all related. They are completely tied together.

So we usually joke in the office, "You can have it good, fast or cheap. Pick two." You can't have all of them. So you got to pick two. And then they start to understand. That kind of falls in the same principle here, they are all interrelated. If you want it done the right way, you've got to work with us. And if you're not going to work with us, the project is going to fail from the beginning.

And I use pretty harsh words when we're setting up that Initiation phase and actually put it on those terms. If you're not going to cooperate and work with me on this project, it's going to fail. If it fails, you are not going to meet whatever your goal is. So we need to work together on this. It's got to be a full partnership.

So where do we begin in all projects. Well, the first problem I had, that's why I put it up here, who are the stakeholders, because I would get a project where somebody comes in and explain they have to build XYZ application and get it going. I don't necessarily know that they are the person who is responsible.

They might have been assigned that task by somebody else. And how do I even know that the task that they've given me is what really needs to be achieved. Maybe this is a perceived notion that they need to get this application.

I'll give a really quick example, and it actually fits to all of these, requirements, resources, the literal scheduled risk. We have a blue-T form. It moved from one department to another department to do some internal processing.

A lady came up to me and she says, "We need to do this blue-T form online." I'm like, "All right, whatever. Some blue piece of paper. Some T-dash, whatever, a bunch of numbers, didn't care."

So I sat down and I'm looking at it, I said, "This thing's kind of complicated. We can do it. It's just going to take a little bit of time. Can I ask what this is for? Why do we need to get from this department to this department?"

Rule 1: who is the stakeholder? She identified endpoint and start point, OK. "Let's have a meeting with the head of each department of each one of those and you. Let's make sure that this is really what's going on."

And in the conversation, the other departments said, "Well, if you get this information to us electronically, we don't need that blue form." Now, I have a whole new different goal. The goal is now changed.

The blue-T form actually makes no difference whatsoever. They just need a piece of information delivered. That's a whole lot easier. So then we started negotiating that to find out that there is a third department that received information after that.

If I didn't have that conversation to actually tried to dig out who  the stakeholders were, I would never realized that the end result was actually a relay from one department for approval and then sent to a third.

And so that's a whole lot simpler, because there's a lot less work. They were doing the old method, the paper method which has a lot of processes that are built on paper. And when we go digital, the first thing they try to do is mimic that paper environment digitally, instead of looking at how to create efficiencies.

So I really looked at the web as we get moving forward and as everybody kind of doing CMS and our time screwed up. We can start enabling efficiencies in our departments. And make things better for them.

So all of that kind of looks at the very beginning: who the heck is the stakeholder and asking the silly questions. Why is this important? I just want to understand. Help me understand you.

OK, so let's go back to the beginning here: Scenario A, the loss of control, the hybrid department, blah-blah-blah. The stake holders, who are they? Well the department chair, the vendor and the administration, those are the key ones.

The vendor accepted the project from the department chair. The department chair is trying to get something done but as we read into it more, the department chair was ordered by the dean who is being ordered by the provost who is actually was being ordered by the president of the university to do something.

Well, now my stakeholder list got a whole lot bigger and had a different mandate. Then as you understand, we have a procurement issue, so actually, over here on the other side, we should have had the purchasing office because they all procurement rules, so now they have a $4,000-5,000 bill with the vendor and we have no authorization pay that.

Why the vendor didn't actually check to make sure it was a valid purchase order? Actually, I don't think it had a purchase order. That's even funnier.

Anyway, bottom line is somebody's foundation account had to be dwindled because they couldn't pay for it any other way but he had to pay off the vendor. I essentially had to flush the project because what was developed was nasty. I mean like Grade A nasty. It was really, really fun. There wasn't any animated GIFs in there but it should have. It would just put icing on the cake.

Let's go back to the next one, minor upgrade with this TER. You got this Person ID that nobody seems to know. How the heck how I am supposed to fix the problem when the people don't even know the information they are supposed to enter. That's just bloody stupid. I don't get it.

So what do you do with this one? There are so many people that you have to talk to but this is your hit list to even try to figure where this falls in the overall structure.

So obviously the Business Office, the financial director. I'm also going to need who ever is doing the payroll because this type is in payroll benefits and taxing so they need to figure out what this Person ID is. And so for this particular task, we found out that Person ID could be added to paystubs. Then do it. At least we have a spot for people to go look.

So that's how we started to achieve some of these little things. But right there, we had a missing piece of information. It would be great if we can have a link between the username and the user can just authenticate, "Hey, here's your Person ID. You're done."We'll work into that as the business process is moving online but you can see that if I don't find out about key people across the list, I'm going to get lost fast.

New front door, well, new president of the university, you know they are going to want a new front door. So who does this involve? Everybody.

It would have been a shorter list to type everybody. I hate to do main page redesign. I just sit in the corner and feel like a puppet, "Yes, I'll do whatever you want. Doesn't matter what I say. It doesn't matter how good the design is, you know you're going to have some 12-year old in some administrator's home that's going to say , "No, that should be blue!" Whatever. That's fine,  designed by committee.

Yeah, I'm always an advocate for bringing an outside firm in because they actually pay somebody to do it for them even though they are paying really silly fees, they listen, "God forbid that we're the experts that actually know what we're doing but that's all right. Ignore my payroll, that's fine.

But these all go through the same process. When I do this, this is essentially my hit list and I sit down. That's my meeting with the people, "OK, who else needs to be in this room? Let's write down all these notes. Let's find out what's the risk, if this doesn't work, what breaks? What stops it? How many people does this affect?

Systems analysis, this is always fun. This is where I finally identify all of those key people and then I have a brief meeting with them identifying the project and I say, " "OK, who is your functional person who does this job on a daily basis?" because that's the real person who knows what's going on.

It's never the department chair. It's some lackey in the back room. That's the person with all the knowledge. Get them in on the meeting. That's where the systems analysis phase comes in.

So I ask them to walk through the process. Educate me. I don't know what you are trying to do. I want to make sure I understand everything. And the first couple of times you do this, you'd think I have an awesome meeting. It's great. I know exactly what's going on.

I promise you. You will repeat this phase three times, at minimum. You will not identify the requirements on the first round. You'll gather all the information, you'll type up a document, you'll send it back to them, and they'll say, "Well, that's almost right but you missed this, this, this and this."

What's happening is now that it's on paper, they are actually starting to think through all the other details. Then you document again and you ship it off to them again, and it comes back, "Oh, guess what? You still forgot some more." I've never ever gone through this phase without repeating it three times. Usually, it's four but three is kind of a minor one.

This is your job, and it's hard to do. You are the one changing things, the evil person, "You are questioning my business process. How dare you?" Well, you can find efficiency can save you a whole lot o work. Let's talk about it. And sometimes, the consultant, I also put therapist behind there because usually things kind of spiral out of control. "All the office politics! I don't want to hear it." Calm down. It's all right, we'll get through it.

So here's what you need to know and activities you need to process for analyst job. Your job is as a problem-solver, communicator have to maintain professional ethics through this whole thing. You are going to learn some of the nitty-gritty, not so pleasant side to these processes and sometimes, things that shouldn't happen.

And so if you find something that you know is going on that shouldn't go on, you have a code of ethics to report that. You have to. If something is going on at the university and somebody is going to be nailed on it later and you knew about it, guess what, you are associated. So you have to report that stuff.

This kind of person, if you are doing the analysis phase, you have to be disciplined, you have to be motivated to go out there and ask these questions and push through it. And these are the kinds of things that I do with all the people.

So I am sitting down and talking to them. I'm getting sample data from them, "Give me a sample of your form. Give me a sample of what it looks like when you process the form. Give me a sample when it leaves. What does it have in coming all the way?" Questionnaires, I have mock-up prototypes. And I do prototypes. These are nothing more than just paper. I'm scratching on them.

"This is what I'm thinking of. Is this OK?" And as we move on to the project, it gets more and more defined. I'm actually mocking it up in a design program, Photoshop or something, before we actually build the final thing.

And this whole goal, this is what you are shooting for; I need to understand their workflow, what is being delivered, any reports, what their overall objective is. Sometimes, what they think is the objective is not the objective.

So this is the traditional method. I don't know how many people have seen this before. It's always kind of fun. The top one here, I'll just read them off to you.

It says, "How the customer explained it." Next one over, "How the project leader understood it. How the analyst designed it." Next one, "How the programmer wrote it. How the business consultant described it." They always make it sound awesome. "How the project was documented." That's my staff.

"What was actually installed. How they were built. How it was supported." And finally, "What they really wanted."

It's funny because it's real. We all know it. We've been through it. It doesn't matter if we're talking about a webpage, or a building or a skyscraper. It's the same thing. It's a project. It's a process. So we come in the communication mode.

This is the reality of it. When you switch into project management mode, you're actually a manager. And you're a manager with strings tied to you all over the place, and the strings are being yanked on you at all times. About 80% of your time will be communication. You will feel some days that you're getting nothing done, "All I do is email. All I do is calling people and meeting."

I'm sorry, that's your job now. When you're doing this, that's the reality of it. You're going to be doing this. After a while, you'll start to get into the hang of it but you have to remember this, the reason that we continually communicate only 50% of what you hear is only retained in the short-term memory within an hour after you leave. That's kind of morbid, isn't it?

It drops to 25% retention a month later. That's terrifying. That's why this communication piece is so critical. It's not volumes of communication. It's specific, concise points of communication. That's the goal.

You are trying to make sure they understand, and different communication types won't process that, that's kind of normal.

So can get in your way? All kinds of stuff. When I hear somebody say, "It doesn't matter what you build. It can work. Oh, that's a stupid process anyway." You need to get those people out of your project immediately if they are like that. Or you need to go above and get that fixed. You cannot have people negatively attacking the project or another person or anything else.

If I know there is a problem/conflict between two personalities in two different departments, and they are the key people, I find somebody else in one of those sides. You have to. You can't put them together. So if you know there is a conflict or a problem, you are going to be good to go.

Another problem I see especially when somebody's new to the interview process, you sometimes get a preconceived notion of what I think they want. And so I kind of mentally click off, "Yeah, whatever. Keep talking, dummy." I'm jotting my notes of what I think they want. That's a major, major no-no.

You got to really pay attention and actively listen with them, repeat what they are saying and try to understand. Make sketches or make mock-ups, do whatever. Bother my CIO, he has a little issue there.

Having a conversation before you even have the entire thing thought out. He has already jumped ahead to what he thinks I was going to say. OK, let's try that again. What I was getting at was… and I come back at it again.

So if you get somebody that you're interviewing and they have that interruptive approach, "OK. I hear you. Let me try to talk this time." What I'm saying is, this is a process or whatever, is presuming conclusions part. This is one that I think for the most part is the end user has a more of an issue than the people who are actually doing the development in our scenario because they are assuming a lot of stuff that's going to happen.

So how you make things succeed is you really push that active listening component. You pay attention to who is talking. You keep asking for clarifications. I am constantly asking. I feel silly, and sometimes I have a couple of my staff saying, "Are you hearing them OK?"

I hear them, but sometimes, what they're saying does not make 100% sense and I want them to say it again in a different way so I'm sure about what they are saying. And sometimes I am right the first. I did actually understand them. You need to make sure you go through that. So this is kind of a normal process and as you are doing communications, that's how things move.

Decision-making factors, goals and motivations, all decision in any business, in any economy all focus around money. You look at the university, all decisions focus around money. If you follow where the money is, you'll know where the decisions are being made.

I tell this to my staff all the time. If I don't understand why they decided to do this instead of this, follow the money. It always explains the answer. So when you are looking at that, you need to find the motivation is. What are they trying to achieve and usually, you have to follow the money, where are they going to get more befits and more resources and more whatever, more staffing?

You need to go through and find out who has got the information. Who has the influence? Because that's going to help you in trying to get additional resources in resolving any disputes. So you got to know all these key pieces of information.

Here are some major barriers. You have the conflicts of tasks. That happens when you get like three major projects dropped on you in less than two hours. It happens frequently, I'm sure.

Sometimes, you have procedural conflicts. Sometimes, you have interpersonal conflicts. We had a major interpersonal conflict in the office a week ago. I had to ask two people to leave the office for an hour and just get out, get some fresh air, come back and we'll try it again.

It happens on occasion. People get so worked up on their job. They get stressed and they take it out on each other. That's kind of our job to step in and say, "OK, you know what, let's calm down a little bit. Let's go for a walk for a moment."

I'd rather lose an hour of productivity because they left the room, but at least, they are not killing each other which would lose productivity permanently. So you kind of have to make a choice.

So when you're trying to move through this, you need to make sure that you're sharing information back. This is an additional communication piece to your stakeholders, to the business process people, to everybody else. And you're trying to resolve these conflicts.

So this is kind of your outside influence. Dilbert and the boss: you'll be in charge of this project. "So what's my budget? "I'll need to approve all expenses." So who will report to me?" "Well, you're team will actually report to me and I'll tell them what to do." "Well, I'll start on the project plan." "I kind of have that in my head already so skip it."

Hypothetically, who would take the blame if this project failed? We know the answer. You're in charge. This is reality as well. If a project sponsor does this to you, you don't really have a project and you need to just politely tell them, "This is not a project. I'm not really in charge. If you are going to hold those kinds of things over me, I'm not doing it."

And if you get pushed back in Administration, you can push back saying, "A real project actually has process. It has control. It has resources. It has reporting. What he or she is doing is actually stripping me of all the ability to actually do what they want me to do. So I will do it but you will have to give me these components so I can actually do the job."

And I had to get in to somebody's face once. I've never had an issue again. And I'm not being disrespectful. I'm being very serious about it. I really do want to help people. I think that's one of the reasons I like project management. I like web development but this is more what it's like. And that whole point: do one grave thing today and then run like hell.


You've got to get out there and get in their faces a little bit. If you are not, you are not really doing the job. So think of project management in the terms of stepping way outside yourself really diving into somebody else's business processes, diving into their workflow, diving into whatever is going on, and try to reveal what's happening. Those things are very, very important.

I've got a couple more pieces of information. I will bring out this kind of normal slide. We have the information posted on the website shortly. I'll get that to the department chairs at the back of the room. Hey, Steve!

So let me also pull up one other thing. And this is something when I was having a really, really, really bad day. And this is my vent session to myself, so I thought I would share it with you because this is essentially, all about resources. So here it is.


"Pledge your support for the Web Development Office today," in the style of a public television appeal. If you're not taking the opportunity to become a friend of the Web Development Office, now is the time to do so. The Web Development Office offers so many different services for your department free of service 24/7.

Make the difference for institution today. Support the Web Development Office. Only one in 50 services of the Web Development Office services actually lands anymore than an anonymous support. With your help today, you can make that difference for your institution or your department.

Pledging is simple to do and such a great way to effect your web presence. Please, check out the pledge levels below.

So I had really good time doing this. I felt better at the end of it. And I knew that I had to share it because I thought you'd get a kick out of it. Anonymous, essentially, yeah, you got us in a corner. We'll do it again because we have to.

Contributing level, $1,000 bucks. We'll provide you with a redesign of your department, complete it, have it ready to go, good to go. I think so many people come into our area, they just expect, "Oh, it'd just automatic."

We put a little time into that. And I'd like to actually give my students the benefit, once in a while or hold a party, "Hey, good job. Yeah, right." It wouldn't kill you to cough up a little cash.

Developer's stage, we'll build that special application you've been building or become our next priority.

Provider's stage, we'll develop that new front page for your institution, complete with redesign of secondary levels, modifying standard templates for your institution to match. Notice I put little carrots down here.

Please note that this level has a time resource allocation set to a minimum of three months which should begin immediately after any required committee meetings have discussed or agreed upon the design technology and content modifications.

This is reality, folks, you got to understand this.

And then finally the host one, the sugar daddy level, yeah, we'd be doing that content management system you've been working on, no problem. Please notice that "right away" means a two-year installation, configuration and transition period which is required for all new CMS installations, which would begin at the moment of the purchasing of the required hardware/software, installation of the software, and training has been obtained.

By the way, there will be an additional staff person added permanently.

[Applause]

This kind of stuff I think, needs to get out to people a little bit more. They don't understand that we are a beat-to-death horse. Come on, now. Give us a little more resource. Give us a little more allocation. But on the other hand, we need to cough up, too, and give that communication mode back.

So that's the gist of the whole thing. How much time I got left? Hey, two minutes. Awesome.

I can put that up there, sure. I thought that was funny.

I was having a horrible day and I felt so much better at the end of it. Then I realized, "Well, that was stupid." Whatever.

Here is one thing that I've come to notice and I want to share with you. This is really kind of a key thing. I didn't have the presentation so let me explain this. How do I estimate time for a project because this is an important one. It's a real simple rule.

I ask each person who has a key point in the development of it how much time do you think it's going to take you to build this? And I ask them three times. I said your best scenario, your worst-case scenario, and your most likely. If you ask them just one thing, they will not give you the answer.

I add all those times together independently. So I had all my best-case scenarios, all my worst-case scenarios, and my most likelies. The formula is this: it is four times the Most likely plus the Best-case scenario plus the Worst-case scenario divided by six.

It's essentially an average component. It's a little bit larger than the Most likely. That is the actual scenario I've hit time targets every single time on schedule. It's a trick. So it's 4 x Most likely + Worst case + Best case / six. Rock star, it's good. Thank you much, guys.

[Applause]

I have time for one question, oh, OK.

Yes.

Audience: Just curious. How many students work under you?

Speaker: Well, I'm on the top floor, so I'd say all of them. I have a ten-student staff and I have a large number of resources within the IT Department and elsewhere that I could lean on. I have one additional full-time developer. Our school size is about 7,000 students so it's not super-huge.

But we're normal operating budget. I have enough money to buy a couple of new computers every year and that's it. So if I need something more, I have to go begging. And they always knock on the door asking, "Hey, can you provide?" And usually, the answer is, "Well, maybe. What have you got for me?" But you have to ask that back. That resource allocation part is the big one so manage that. Out of time?

Host: So this was mmp3. Please be sure to fill out you evaluation forms and turn them to my co-chair extraordinaire on your way out of the room. Thanks so much, every body.

Speaker: Thanks.

[Applause]