MMP4: Web Project Management

Jesse Rodgers, Associate Director, VeloCity, University of Waterloo

The audio for this podcast can be downloaded at

[Intro Music]

Announcer: You’re listening to one in a series of podcasts from the 2009 HighEdWeb Conference in Milwaukee, Wisconsin.

Jesse Rodgers: Talking about things that we do, I don't want to get into the dogmas like I mentioned at lunchtime. But just general things with web project management,  kind of go through this whole thing.

Is there anyone from Canada, other than Janus who I drove here with? Oh, look at that. So somebody might know what Waterloo is. We don't advertise in the States' much so...

For those who don't really know what this is, Waterloo -- and actually this is 2006, now, there's a building here, here and here. RIM have done some stuff here. All your Blackberry's come from here. The university itself is here.  Actually, it's true. All Blackberry's are made in Waterloo or the region anyway. 

And that's our Research and Technology Park up there. And there's all kinds of neat stuff there, and the lake that really kind of smells in the summertime, but that's the university. I actually work in this spot down here which is the Velocity residence for entrepreneurs.

But before that, I worked in the Special Projects Group building software co-op which is actually in this building. We have an entire building dedicated to cooperative education. And we did a lot of project management trial and error, every four months cycling through students. So that's where a lot of this comes from.

But to give you another idea, this is how far we drove. That's the bottom of two Great Lakes we skirted under. And we started over here and Toronto is over there, which is how everybody in the US references Canada.


And it was James over there. He's presenting tomorrow afternoon. We drove and it was really very good until we hit Chicago. We made good time.

Anyway, the other one I presented in Cornell and that was a much better drive. It's nicer in upstate New York. It's not as boring as going through Michigan [Laughter], lots of McDonald's though. 

Alright, so project. Here's your great definition. A project is a temporary endeavor undertaken to create a unique product, service or result. And that's from the project management bible and that's a great definition.

When we talk about web projects, you can build a few web pages, you're developing a simple web app, collect student information which is pretty common Twitter, Facebook, Ning or whatever, that is a web project. You're trying to put something out there, you've got a goal, you've got an idea of what you're trying to do.

Extensive kind of management systems, that's  a huge web project. And the common topic here right now is word press. That would be a little web project.
But they generally feel a bit like this, especially kind of management systems. Everybody in here gone through one of those? These are engineers in our campus celebrating the fact that they actually get to graduate. And they do this, yeah, engineers.

But in higher education, projects are a bit different. They are ongoing with many false starts, chronic scope creep, governed by committees, and success is not often tangible. And that's really what we deal with. I think everyone in this room has dealt with this feeling all the time.

And one thing I should note is that before this, before I did Special Projects, I was a web communications manager for the university. I had a home page and all the politics that went along with that. So I'm familiar with not having tangible results on our projects.  And really we get a lot of chaos. We do a project in higher ed, we get developers that come in sometime. We don't know when. Designers that rarely answer email and when they do, you can actually read the emotion in it, in the 'snarky' email stuff. Not just stereotype designers.

Developers are sometimes worse. Actually, they are usually worse. The department wants to see it termed 'pedagogy,' something in their parents. I hate that term, because there's no way any parent knows what that means. I don't know of any people other than the ones in the learning technology groups actually knows what that means. Just say 'education.'
Committees, that is just chaos with usually three hour meetings and never-ending change requests. You always think you know what you are doing, somebody wants something else.

So what can you do to do a lot of this stuff, software engineering has been doing this for quite some time. And there's a really easy process. How many people have heard Waterfall, Agile? Waterfall, any body heard Waterfall methodology? So not a lot of software engineers in the room.

Waterfall was pretty much the way everything was made. And it's "hit a milestone, go to the next one, go to the next one, go to the next one." Just kind of keep going. And then Agile came along. Now, it's crazy and dogmatic.

But really, we're talking about is you pick a dev strategy. There are a lot of them out there, depends on the project. But you need to understand what you are doing.

Version Control, number one recommendation for anything that has to do with anything with code, Version Control. And with content, you know what, when you are creating content, you're putting it on the web somewhere. And you' re going to rely on Facebook who delete somebody's web page? Are they here? They are not here. But things go missing. Back it up. Keep versions. Issue tracking, really good to say, "I told you so," but these things are really common. Software engineers do these sort of things. They have strategies. They use Version Control. They do issue tracking.

One thing we don't do in higher ed and engineers won't take this on, is where do you start? You start with project definition, and you start at I call them Memorandum of Agreements but I was president of the staff association at the university so I get into those words. But essentially, the committee meets, sit down and say, "What are we going to achieve?"  In that, you define the goals, the objectives, and/or the outcomes. And sometimes people get objectives and outcomes mixed up, it's OK. But what are you trying to do, not get into the very simple discussion of "Oh, we need to put a video up, Oh, that's YouTube, no that's something --" no, don't go into that discussion yet. Get into "you are going to put video up."

Get into things like "I want to get 2,000 people to see this," "I want 30 comments on it." They don't have to be realistic goals. You don't have to have realistic outcomes on this. You don't have to have stuff that seems realistic because it's going to take you awhile to learn this stuff. But set something. Set something to measure yourself against and something you can go back to and improve upon later.

And get everyone to sign it. This could be a long meeting but it's really important. Has anyone in the room actually done anything like this? Like this where you get goals, outcomes, anything like that?

Audience: Yeah.

Jesse Rodgers: Everybody signs it?

Audience: Yeah.

Jesse Rodgers: And it works?


Audience: So far it's worked for us.

Jesse Rodgers: And how long have you been doing it?

Audience: About six months?

Jesse Rodgers: Yeah, it's a new thing. It works, though. It really does, but it can't stand alone.

But when it gets to this thing -- I work in a residence, I run a residence at the university that's focused on entrepreneurship and startups. We run 70 students through this whole thing, big thing we tell the students about building products and services. But essentially, it translates over to a lot of the stuff that we do in higher ed. And we don't focus on that. We're delivering a product. So to get there was the process.

Now, at lunch there was talk about all the different parts of all the different process and the that type of thing. But you need to deliver something and you need to end it and move on. And that's really an important thing. I'm not going into this right now. 

This is a process, and this is to get us into a point of where we start with milestones, we have responsibilities, and then things go public. And how we get into this process is kind what I'll go in a bit more before that.

When we are looking at this stuff, the triple constraint really, if anybody has heard anything about project management, scope, time, cost. That's your big things. I mean these are all three things you got to worry about in a project.

It essentially "what am I building," "how long will it take," "how much will it cost to make." And it costs to develop things. I mean one thing higher ed is chronic at, it's "staff's time free," and it's really not.

And it gets really bad when you go higher up into the management structure of the university and you have people tat are paid a lot of money and they are sitting at committee meetings all day. That costs a lot of money. But we don't look at it that way. We don't look at it as resources. It's a bit of the thing that if you are not in a position of influence, you might get scoffed by people above you. But if you start doing it, you start showing it, there's a lot of value in that in terms of saying this many hours to produce this and might not be valuable today but two years from now, you've got a lot of projects with a lot of examples. That's a culture thing, I think, but it's a good thing to think about.

But on that first point, I mean how do you define what you're doing? In ideal world, projects sponsor asks for something that needs to be built. I mean very specific, "I need a blog up," something like that. You meet with a committee, you do your Memorandum of Agreement, you get a scope and a timeline set up when you want this done. You sketch out the application, you call on resources that you need. You don't call on the resources up there and then figure all that other stuff out. And you develop the other application, get feedback, tweak, done, so just a typical dev process. I mean we get "I would like website that looks like Brown. [Laughter] Next week would be perfect. Can we have video and live chat?" People actually like that. "And we want social media." That's my favorite because nobody really gets it. "But we want it, and we like it," and that's the way it works.

In all, this is what we deal with. But it still goes back to the key points that we're trying to do. When we get into our resources, and this is something I don’t think it's even possible to modify it right. You actually know the skills people have and if they are available for the project.  I don't know how many universities have really big HR departments. I know Waterloo's is relatively very small. Knowing what skills people have within a management level, within a structure, there's usually two or three different groups that you have working together. People claim to have skills. There's a lot of "I'm really good at Ajax, what's jQuery?" That kind of stuff. That happens.

But knowing how much time they have and getting people to be honest about that is also not easy. I'm bad at that because I'm now past president of the staff association. I never know how much time I have because one committee meeting flares up and I'm talking policy for the next three weeks but being honest how much time people have within a normal workday…
Is there a line of communication between you and your resources, even when not working together in the same place? Communication strategy, "We're going to talk everyday," "We're going to email with this. I expect responses within this amount of time."

Be upfront about what you expect and then you won't have an email unanswered for three weeks that was very critical, and you assumed it was getting done and it didn't because the Spam Filter caught it or something like that, because if you have the timelines, you could always follow up.

So if you didn't get me, you can get back to me what's going on. They might have legitimately lost it. Or "I have been at work for 60 hours and don't really read email because it was a bad week." But that goes to identifying your risks.

What would cause a project to be delayed or fail or usually 'provost'? I mean really what can cause it to delay or fail? There's all kinds of things that can delay that. IT, communications, marketing, the content people are arguing about what font to use, if they were paying attention to Waterloo's branding initiative, it might be they put lasers on the W. I you haven't seen that. Don't worry about it. It didn't happen. What will you do about them? If something happens, what are you going to do? Set a priority. It never goes down to "A server breaks, we don't have money to replace it." Deal with that. It might never happen, there must be something. It may be superficial, just something to at least say that you're figuring out that something bad could happen.

Stuff like "if content doesn't come from Joe over in marketing, who is the backup for that content?" Somebody gets swine flu, who is going to do their presentation? There's a bunch of stuff like that which happens. It really is easy to do a little chart that identifies these risks. And how much will it cost? Very hard thing to do, time and money, easy estimate. Somebody's salary, break it down into hours. I don't know at your school but at Waterloo you can estimate people's salary within 20%, based on what is published online. That's good enough. You are going to add 25% for overhead and then you've got an hourly rate for that person. You can guess how much money you are going to spend on this project.

Nobody might care immediately but it's amazing how you get new administrators from the outside world, the real world. They actually care about this stuff. And they are interested to see it. They may not be able to do anything about it but they want to know about how certain things cost. And you don't even get to the emotional costs. You're just talking straight cost there.  So we've done all that stuff there. We've got our timelines. We know what we are going to do. We need to break down our project. This actually leads into a more Agile thing but you may define your requirements in any web project, new development, new user-testing. Most of you do user testing now. Every body does user testing, right? You do user testing?

You do some sort of public beta because it's really trendy. I don't really know what is trendy and what's just expected. And you fix stuff and then you have it done. Although if you're doing all that in a week, it's kind of hard to do, but something like that you can have.

But if you break it down, like this is the larger one. And that could happen over we don't know how many times, how much time. But if we break it down, into two weeks, what are we going to do in terms of identifying content and doing these things? The original idea would be wire frames. We have client meetings, more wire frames, client meetings. I did a lot of these within a week, going back and forth between the co-op department and my project team, going back and forth, kind of tweaking wire frames right in front of them.

But you break it down you know what you are going to do this week. It works real easy. And what comes out of that though, you're always doing a lot of stuff, right? So that part of it is your critical path. It's the stuff you have to get done this week or you think you have to get done this week or over the next two weeks.

And these other things always happen, though, when you do this stuff. So how do you manage this stuff? You're not going to be good right away.

It's really hard to estimate your time. In the Special Projects Group, this is back in '07, we started off with these type of things. This was my week plan, I did this on Monday, my critical path was doing some demo, doing some thinking which is a nice thing about my job. It didn't really happen though. And do some documentation in terms of what are we doing, why are we doing it, how it fits. What are fits and workflows we are getting from the staff? What I plan to do each day is there. It was a crazy week because we're doing a demo that week, trying to show it to the IT department because we're not an IT. We're a separate project. So we got away for this demo stuff so I put in a lot of time for that.

And then at the end of the week I went back and I reflected on the week. And it doesn't necessarily match up with what I'm doing. This was November '07. That was probably just a month into actually doing this but better as time went on. Generally, it felt superficial at first. But after a while, it started to make a lot of sense in terms of "OK, well, this is more realistic." And what ended up happening is I had less things on this side because I was being more realistic about what I could do in a week rather than do those kinds of stuff.

And I even have things like flu shot. I was getting a flu shot. That's a risk. That can take me out for a week if end up getting sick from it. Not likely but it's a risk.

And I had another one, I had an exec meeting with the staff association that was 2.5 hours, pretty ridiculous thing. But that happens in a day, right? For the students, we had nine co-op students to develop. For the students, we tried this one out for a bit. They had a task group, the name of what they are actually working on, broken down into morning and afternoon chunks of what they are going to develop, what work is going to done and what's the intention.

The work to be done and the intentions are usually two different things. You know what you need to do but I know what I want to do, and they might not match up. There's a few more follow up in the week when they went back and they kind of had a success rate in terms of what they were doing. And they actually got really good at that kind of stuff for a while. But it didn't work as well as we thought for a lot of the stuff.

Like a couple of guys we brought on the project team. They had a lot of experience with our big bad friend, Agile. And if you look at the definition of Agile, 'moving quickly and  lightly.' We're in higher ed, that doesn't happen. But you can. I'm not saying you can't.

But Agile to me, I mean I've been doing web design fro a long time, working with different project groups, working with different stuff. To me, it seems a little dogmatic. We need to follow it and just "are we really going to do this? Are we going to do this like have scrums?"

This is what I think when I have a scrum, like I'm watching rugby. But apparently, that's what it is.

Really when we look at it, Agile's really getting everything out there on the wall for everybody to see. Agile is, if you really follow it religiously, there's a lot of terminology that gets overused, like scrum master and stuff like that. But if you break it apart and look at the stuff that you can use, they're kind of baby steps. This is called "I can bend" wall. This one's at Post Rank by the guy who took this picture. Correct me if I say it's a wall of sticky notes. I prefer that terminology: it's a wall of sticky notes.

But this Post Rank's 8-hour assess, I don't know if you've heard of them, they're a startup at Waterloo's, switched their name to Post Rank. This is how they plan out all their development. They've got it broken down by day. Actually, he's more of an Agile guy. He's actually a certified scrum master. So he has a bunch of other things he can't see in terms of backlogs, and this kind of stuff. That is pretty scary, to get into.

Something a little more familiar. I grabbed this one off Flickr. This someone's personal little wall. This works, too. You got your backlog. You know what needs to get done but it's not a priority. Cool-warm-hot in terms of where you are in the process, makes sense to this person.  Some like that. What you're working on , what's been done. Very visual representation of what you're working on. And this is for an individual, just these little explanations, just something he did for himself.

But if you're in a team of two or more or are working in other things, you can see how helpful this is when you can see what's going on, what's important. Some might need help, what's getting done. That visual is very helpful.

And you don't have to have scrums, sprints and all other fun terminology, just a wall of sticky notes.

Or as my son likes to do, take the baloney and sort it out on the wall [Laughter]. That's not my fault. I'm actually a Detroit fan. That's what it feels like anyway. And our baloney wall was this.  Here is what we used in the Special Projects Group. Our sprint was two weeks. So we did use some of the terminology because we had guy who liked that stuff, made him feel good.

The in-progress stuff is here. All the students, all the coders were there. The GUI folks were over there. Then over that side was a whole bunch of tasks. All the stuff that had to get one. You can see some of them are empty because I don't know where they were that week.

We actually do these stuff everyday. We meet every morning. We tried at 9:00, it doesn't work well with co-op students. Then we tried 10:00, better. And they would stand in the room, five minutes: what are you working on, what did you finish, what are you going to take on today. Have you finished? Goes on to the day you finished it and off you go.
Nice visual in terms of what's going on. And we're in the co-op building of he university which is tons of offices all set up for use. The doors are always shut so you don't get to talk that much. So it's nice to have that every day, to figure out what everybody's doing, where people need help and what the priorities are.

We took on really a kind of a very light Agile process. And how we did it, we broke everything down in the sprints, and then each page has got an authentication  a user can log in, a user can define permissions, and then bug fixes because we just had a demo so we're always fixing bugs.

And as you go on with your sprints, you get the next sprint we're doing feedback buttons need to be blue, tables need to have sorting. These are all nice little one-off things that that all kind of work. Integrate Google Maps API, little optimistic to say that is a one-day project especially if you're in the dot-net project but we said it was a day. We figured it would take a day to do it.  But you break it down to what you could do today, what we can do that, and you adjust. And that's a general process that seemed to work well for us, but it was baby steps getting into that.

The whole thing though in a lot of these things is you need to get involved in what you're doing. It takes at first two hours of your day, to be honest. Or it could take, if you're good at it, it could take you 15 minutes. But it can take up to two hours to really get on top of it at first until you get really good. You get the level documentation built up and then you can scale back what you're maintaining against the floor.

But Basecamp, Excel or Word document works. Everybody's familiar with Basecamp? You all work on the We. You know Basecamp, 30 seconds of this, talking about dogma. Works, though, but yeah, they're blogging.   You break down the project for the sponsor of the project, setting expectations, working with clients, being honest. Everyone's got that 'need to please' once in a while. And if you ask something's that's really cool, they might say, "Yeah, it could be done in a month." And you know in the back of your head it's three months.

You know something's going to happen. You know it's a big project. You know there's risks. But you're not going to tell them. And if you nothing else, just being able to do that, let the sponsors know and be honest with them, very important.

Provide them time estimates for each phase. Set milestones. I know this going to be done next week and here's is what we’re going to do by this point, we're going to do by that point. They don't have to be set in stone. You can move them, even though they're called milestones but you can move them.

You can always adjust to what you're doing. Some thing's can be done faster. Some things can be done slower. As you do it, you get better at it.  You follow up with daily/weekly updates on progress. Senior folks like that. I don't think they read their email but they think that sending them one that says what’s going on.

Some do read it religiously and they'll call you and take more time out of your day in terms of talking about it. It is really good especially if things get pushed back and even if things are going ahead, to give them a head's up. We see this as "we're a bit slow today, we're ordering a bit, we're a bit slow tomorrow, we have to push that milestone back, we'll let you know tomorrow." And if they know that email is coming tomorrow, they know an update's coming, it relaxes everyone.

It really boils down to sharing information. You really are being communicative within the group, with everyone, it's really important.

I'm not going to say project management software, there's other stuff like Microsoft Project, Omni Planning for the Mac user which I love, but I really hate Gantt charts. But if you like Gantt charts, that's good. And Basecamp, and if you really want to, it's all listed in Wikipedia for Project Management.  I'm certain there's some hidden message in that pattern. You can do so much out there. Active Club really cheap one, really works online. There's so much out there. You could just drive yourself crazy. Start with Excel. Start with Word. Start simple. Then figure out what you are going to need for software.

My two final things are Version Control. Who in here uses Version Control? That's pretty good. No, that's OK. You were here last night, too? We're all a bit slow. Actually, I think we left you at the bar.  Version Control, for those who haven't had the chance, this is a typical web-workflow if you don't have that kind of management system. You got a document, you work on it, it goes to the web server, everybody sees it.

You stick in Version Control, you don't have to go to web server anymore. Version Control does. You publish something there. If you get really tricky then you can get stuff like this where you've got testing servers, staging servers, and then you go out to the public and you can push up to that.

Version Control enables that. You don't need to do that but the nice thing is, when you get a big 'oops,' you can roll it back and there's lots of big 'oops' in web development, especially with public documents. Somebody always forgets something. We approve its content, it gets out there and it's totally inappropriate.

You have to roll it back, and you roll it back really fast with Version Control. It's my favorite thing.

Version Control software that's out there; GitHub which is really trendy and popular with Linux kids; Subversion which is now the old one but it's Dreamweaver supports Subversion. It's pretty much a standard.  Team Foundation Server which I had the lovely experience of using for two years. It works. CVS which is the really old one now, anybody who did a bit of coding in the university in the '90s use CVS. They should have used CVS at the props actually generally, in CVS there.

And Google Codes and other I think it's basically a Subversion buzz story. But Google Codes, great for when you're sharing your projects and you're doing stuff like that. But even if you're in a closed project within your group and want controlled access, just a nice place to do things and you can do a few other little things in there.

The other bit is track the project. All those other little bits when you're doing milestones and stuff like that, tracking the project and actually having it tracked using issue tracking software helps do those other things later. You can grab reports and do those separate things.   People here use issue tracking software? See it's funny. You have Version Control but not issue tracking. They're almost built-in to the same system, because every time you commit code, you have to have a comment. It's a habit.

I know. You did a comment that's just white space. But that's why you get issue tracking software, make people do that. It gets a little bit…

Within issue tracking, really the document milestones, you can track conversions, changes, rationale. That's really good when somebody says, "I didn't say that." It's right there. You said we couldn't do this because of blah, right there in the system.

But the other bit is if somebody's sick, you can go back in that system. Or somebody's gone, somebody switches jobs, you can back to the system and find out, "What the heck were they thinking?" Hopefully, generally, maybe.  You can generate reports which is good when we send the daily emails. I was doing that for a few weeks because we had the head of the co-op who wanted to know bug progress. She didn't want to know after a while because we kept getting more bugs. We're solving lots but we kept finding more.

But she appreciated the effort. But it also helps you control your scope. Things like, "This would be really a cool idea, too." We'll say, "Yes, it is" and we'll defer it. You just drop it in the system and there it goes. It really helps with that.

And this is a report out of Bugzilla. With Team Foundation Server, you can do issue tracking in that. We didn't use it because it's way too complicated. It was really hard to use so we would use Bugzilla.

And this is just a picture of it. One day, we started of with a hundred bugs, we've about 806 in the system. 'Defer' is a nice popular thing to do when you know something is going to come, close bugs or fixed ones. We have resolved ones that aren't confirmed. We had a bunch of status.  And I know a lot of people way this. Well, you got all these different words to explain what’s going on, but it ends being internal team terminology, and it works for us, You can just say 'fixed' or 'not fixed.' It really doesn't matter.

But it's good to see these totals because you see progress. And it's really important when you're doing any project, in my mind, this is the number one tool to document your progress.

Celebrate your success. Don't worry about the failures. I mean this helps you with that.

Issue tracking software out there, Bugzilla, Track that's integrated with Subversion, Bugzilla can integrate with Subversion as well. Team Foundation Server, and you can use Basecamp, that's how I like it.

You can use Basecamp for issue tracking as well. To Do List is great for issue tracking. You can put comments on them, too. You can do some really good stuff with that. You can do some really good stuff with that.  But really it boils down to use the process that works for you. There's a lot of strategies, a lot of things, Agile and everything else. But take bit of them and just try them out and figure out what you're going to do. Do things here and there, and as you go along, you come up with a process like this.

And this isn't Agile, but it's not not-Agile. We set our milestones. We do sprint planning. We do sketching. We go through some fixes and then we come to goals and development. Some sprint planning might have to occur again. Then we get our testing and our bug confirmation. How do we get over the staging? Other responsibilities are laid out and there's a recording structure built into that.

That took a year to get to. And we had a lot of trial and error to get there. We had actually extra challenges. We had nine new staff every four months because we are running co-op students that changes every four months.  It took us a bit to get to that but this is a process that worked for us. It isn't a process that necessarily works for anybody else.

In any project, you'll do something different because it depends on the people and what you're building. And maybe that falls under tricks from lunchtime today, because it's a technique, it's a little bit dogmatic, I don't know. I was eating.

But that's it for the presentation. I hope I left a few minutes for questions and stuff. This is how you can find me online, my email, and then a bunch of other places. There aren't many Jesse Rogers in the world, but there many in the world who can find me. Any questions about that, it's certainly welcome.


Audience: Are you saying these can replace for the...

Jesse Rodgers: No, I've actually found the online stuff, anything that's on the computer does not replace that wall. That wall is a very visual thing. You can touch it, and for some reason that works better. It's not the same. It's just the wall.

Audience: If you kind of like add sprinklers to the wall?


Jesse Rodgers: It doesn't matter because it's only two weeks gone. After two weeks, you gather them up, then go, but we wouldn't know. We haven't had sprinklers go off.

Audience: So how do you play that with that?

Jesse Rodgers: 15 projects, well, with the same project group?

Audience: Yes.

Jesse Rodgers: You need software. Well, you can because each Post It note, you get really complicated. You could have a Post It note color for each project. You could break it down to tasks. You could have different sections of the wall for different projects and their status.

The important thing is the progress work for the week you're planning and the backlog. And you can break down the backlog. The one from 8-hour Assess or Post Rank, their wall is for multiple initiatives that they're working on and where they go like that but you just go more complicated with that. 

I would not recommend Sharepoint. It's not good when the software you use makes everybody angry, but I like the wall.

Any other? Yup.

Audience: I used to go out there in terms of project tracking. It's less good in terms of dogmatic [background noise] as say these applications. It's good to deploy. It's very easy to use, and it's free.

Jesse Rodgers: I haven't used it.

Audience: Very few have but it's very nice.

Jesse Rodgers: What is it called?  Audience: Colladitive, maybe I spelled that wrong.

Jesse Rodgers: If you do Wikipedia for project management software and they have the chart, it's probably on that chart.

Audience: Yeah, it's German.

Jesse Rodgers: Any other question? I think they're all… alright, thank you.

Host: Thank you, Jesse.