How To Manage a Software Development Project

– If you have to create a
Gantt chart, get a new job. Gantt charts are bologna. Well they’re not bologna. I say that and then,
(sighs), I’m so torn. (upbeat music) How to manage a
software project. If you haven’t noticed,
we are in a new studio and I’ve got an
exclusive for you today. The reason why is I’m
undecided, it’s a little yellow and I know this,
you’re probably like, “Well is that
supposed to be brown?” I’m gonna tell you the
story to help you actually understand the lesson
I want to share with you which is managing a
project and how to go wrong. If you’re frustrated
because you get people to build stuff for you
and its not what you want or the timelines are way
longer than you had thought or proposed or even communicated
to maybe your customers. Or the expenses and
the cost have been kind of blown our out of control. I mean, I remember
one time a guy called me, 1.5 million invested
in the software product over a two year period,
still hadn’t launched. If those things, maybe
it’s not as bad as that, but if you feel like
you’re trying to build the right product and
you can’t figure it out, I want to share with you
guys my strategy for managing really any project, but very
much specific on software. And when you do
this right, the cool part is you get working
product in front of a customer, things that your customers
wanted in the first place. I think most of waste in
a company is building things for people that they
never wanted because you weren’t listening properly. And then finally,
making sure that they’re done on time and on budget. This backdrop, okay,
and I’m not gonna throw Tim. Tim if you watch this
video, man I really appreciate the energy and effort. I had a vision. I was like, you know
what, we’ve been doing the brick background for a while. A
lot of people didn’t realize it was real. Many times I’ve
gone back, knocked on it. This is, hopefully, definitely
real because you can see the dark spot,
stain, the knots, the holes. It was like I had this
vision for kind of like this rustic wood
type of organic thing. And not that we
didn’t achieve that, I just think the color
was off and it showed up and I wanted to shoot
some videos so here’s the deal. I want to share with
you what I shared with Tim because I hired Tim to do it. We had to engineer this thing. I mean, it’s heavy. It’s got aluminum frame,
it’s actually a quite cool piece of studio gear. But I really learned how to manage projects
back when I was 21. I got a job that
I should have never got, managing a team of engineers
at a company called Syncrude, getting paid way
more money than I probably should have been getting paid. And my boss pretty
much pulled me aside, ’cause we interviewed
over the phone, he looked up my resume,
maybe he didn’t do the math on how old I must
have been based on when I graduated and stuff. And I was a contractor,
and he pretty much said you have two weeks
to figure this out. And I didn’t really know
what, figure this out, means, but I did what I hope anybody
would do in my position, is I went to the library
and I got a library card. And I started buying
books because I was gonna be responsible for
about a team of 30 people. So I needed to understand
how to manage those people, how to lead them,
how to set expectations, how to interact with vendors. So I rented, rented, borrowed. I mean most of
you guys are laughing. You probably have
never been to a library. Isn’t that funny? We live in a world where you’ve maybe never been to a library? And I got books on
project management. I got books on
technical architecture. I got books on understanding
the world of consulting and that’s where
I learned Gantt charts. Still undecided
how I feel about them, but that’ll be
for another video. And it was through
that experience at 21 to 23, where I really refined my
approach to managing projects. And what I want to share
with you today is the four key areas that I think
are super important. Number one is time blocking. When you build something new,
you need to set the constraint If you don’t have a constraint,
then anything is possible. The scope for what you
want to build can expand way beyond what
you could possibly do with the resources you have. And it’s super
important to actually say, okay from a time point of
view, we’ve got three months and we’re gonna build this. If you’re into
agile development, which I highly suggest, typically you’re doing
kind of a six week product kind of roadmap with two
week iterations and sprints. But regardless, no
matter if you’re starting off from scratch and your
first time building software or you’ve got a
team, you want to set a cadence for time
blocking what gets built in that time frame. So that’s one. Number two. You want to make sure
that you define the outcome. And for me this is really
from the users point of view. Most of the features
you’re gonna build that are not paying
down code debt and kind of fixing things, performance,
that kind of stuff, or fixing bugs, are
gonna be focused on the user. And really trying to help
them achieve what’s called the desired outcome. And the way you do
that is user stories. So making sure that
you have a defined outcome for what you want to have done. I wanted this built
and we talked about it and I was like, you know,
it’s gotta have handles ’cause it’s a big heavy piece
of gear and it rolls around and it’s in a studio
and I want the whi… And there was all these
things and one of the things that I felt wasn’t really
captured was the outcome goals. What the specs were. We talked about it, you know,
but it was never really written down,
drawn out and really like, ‘kay, this is
what I want you to do. And look, everybody
has a different approach for managing their stuff,
but when I hire and delegate this to people, I’m just
gonna trust that they’re gonna do it the way
that works for them. This is just some
feedback and thoughts on how it could have went better. So, time block was there. I had a date that
I needed it delivered by and we were late by two
days and I’ll tell you why, because it’s
number four in this video. But, it was really
about making sure that the outcome
goals are well defined. Number three is you need to
make sure that you prototype along the way. And what happens is,
and this is an example, is the stain, the color,
instead of coming in yellow, coulda came in on the
brown tone that we had actually screenshotted and sent to Cross, but the reason why
is it was never tested. It wasn’t something like, and many times when
you’re building software, you communicate the
specifications using words, text, a document
and I can’t tell you but if I wrote a paragraph of an outcome I wanted and
we had two different people read that paragraph and
build towards what they think or how it should work,
we’re gonna have two different experiences. So, to me, it’s all about
prototyping the user experience, so it’s called the
UX, how it interacts. How the feature works
because there are 100 different ways you can
implement something. And also the UI,
or the visual design. How do you want
the colors to look? How should the
buttons be stylized? What layout and
spacing should you use? And I think that regardless
of what you’re gonna build at the end of the day,
if there’s elements in there that are unknown,
you need to prototype. You can do that
through a designers mock ups. You can do that through
clickable prototypes using Keynote or UX Pen, or
Balsamiq, or whatever tools. It is very important approaches. So that was number three. Four is you need to make sure, and this is
what happened, is if there’s dependencies
amongst the project, right. Other areas, other
business units, other people that you communicate with
them early and then often, especially if
you own the project. So what happened here is we
had to work with a contract company to do a aluminum frame
and communicate those specs, but the timelines
were never asked for and/or committed from that person. The other thing is the
custom stain for the backdrop was never tested early in
the process of the project so that if there was
a discrepancy in color, because there’s a fixed
timeline, that we could have fixed that early
and get that resolved. That to me is probably
the number one thing that every founder gets wrong, is when you start a new project, and this usually
comes from three key areas in your business. The technology that you
might assume is gonna work. So maybe that’s an
integration, it’s an API, it’s your own code, technology. Second one is marketing. What are the dependencies
once you build this that marketing needs support on? So maybe they gotta
put a campaign together. They need to put a
new features section. They need to add it
to the pricing page. So there’s
marketing dependencies. And then finally, operations. So, you think
about in your business, there’s like
administrative support or it could be billing,
or whatever it is but there’s an
operations component and those three
areas are dependencies on the overall project
that need to be communicated, need to be understood,
and if there’s legal or anything else that
has to provide feedback into the timeline of
getting that project done, start it early and often. So real quick, those four and
I’m gonna share with you guys a myth that every
founder believes in that’s just simply not true. One, is you need to time block. You need to set the constraints. Number two, you need
to define the outcomes from a customer’s perspective. Number three is you gotta
make sure that you prototype and test the user
experience and the UI so you have have
the yellow background. And four, you need to
make sure that you test, or start with those
defined dependencies and make sure that
they get rolling faster than waiting ’til
that moment in time to actually move it forward. The myth that I want to bust
for you is that any product survives first contact
with the customer. The truth is, no matter
how great of a job you did, and Tim did an amazing job,
there’s gonna be iterations so actually build
that into the schedule. Build that into your plan. That’s gonna make
you a happier founder. Hope this video
finds you incredibly well. As per usual,
I want to challenge you to live a bigger life
and a bigger business. I’ll see you next Monday. If you’re the type
of person that likes to subscribe on things,
click the button. I’d love to have you
part of the community. I’d also encourage you to
subscribe to my newsletter where I share
incredible new, exclusive, only ever found
on the newsletter. And if you’re
ready to get going, I got two other
videos queued up, ready for you to keep watching. Have an amazing day.

Leave a Reply

Your email address will not be published. Required fields are marked *