[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.
[Laughter]
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?
[Laughter]
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.
Yeah?
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?
[Laughter]
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.
[Applause]