Project Management
What the Web Developer Learned from the Stage Director
My wife is known by myself and friends as someone who’s excellent at managing projects.
Her ability to start from nothing but a goal and produce real results with many moving parts always impresses me.
Her secret is that she approaches projects with the perspective and skills she developed in theatre while producing and directing stage plays in college and later managing a cast of a hundred in professional theatre.
I wanted to learn more about her process so I asked her to describe to me how to produce and direct a stage play.
The following is what this web developer learned from the stage play director, and how to apply her methods to any good development process.
Directing a Stage Play (In Brief)
Read the script over four or five times
Before anything, become very familiar with the script until you know it inside and out.
Start at act one - scene one
- Work through the script and make notes on what’s needed to produce each scene.
- Research parts of the script as needed, such as time period or subject matter.
- Define elements such as blocking, set design, ect.
Rehearse early
After casting, begin rehearsals early.
- Start with a sit down to do read-throughs and discuss the characters.
- Later progress to the stage.
- Refine elements of each scene over time.
- Provide notes to actors on specific changes or areas for improvement.
Meet separately with other departments/crew
Schedule miscellaneous meetings and discussions with set designers, sound, costume design, and any other parties that support the overall production.
Communicate the vision for the play and get their feedback on ways to make it happen.
A Summary of the Strategy and Tactics Used in Modern Web Development
People often ask me about the process I use to develop large scale web applications.
The following is a brief introduction (high-level overview) which I use to begin to explain how it’s done. There are links at the bottom of this post to begin to explore the process in more detail.
The discovery processes and development plans will always be customized to clients’ individual needs. However, the following process is one that is very typical for many clients. This is not just my method. It’s a common process for many development shops and consultants.
Discovery
Project kickoff usually begins with a Control Memo (a master project document), which serves as a communication tool to explore a client’s needs for the project. I use this document as a discussion point with clients to:
-
Discover more about their project’s business, marketing and technical needs.
-
Record what I think we all already know and get clarification on what we might have missed.
-
Be in a position where we have collected enough information to provide a client’s team with the following:
- Functional Specifications
- Technical Specifications
- Milestones and Schedule
Development
After technical discovery, in development I use a modified version of the Scrum development methodology, one of the classes of Agile development.
The requirements documents, final mock-ups, and design elements constitute the Product Backlog in the Scrum process. The Product backlog is the culmination and summary of needs defined in the:
- Functional Specifications
- Technical Specifications
- Milestones
- Features list
- List of mock-ups and design elements
All technical documents are kept under version control.
Main development typically takes place across periods of 30-day code sprints.
Notes to Developers
I've been both developer and manager for years on both large and small projects with various sized teams. During the week to week management of these teams I tend to send little notes to help guide our work process. This week I have been breaking in a new team.
I thought it might be useful to other technical project managers and team leaders if I shared some of this week’s raw notes. I hope it’s useful for other managers to have a glimpse into the day to day notes of another in their same place.
Time Sheets
Please enter your time regularly into Fresh Books. Smaller more frequent time entries are preferred. Try to break them down by tickets and tasks in those tickets. Please always include the ticket number you were working on.
Please keep your entries up to date daily while on a project.
SVN
I believe in update and commit often.
Make sure you update and resolve conflicts before committing.
Enter in notes about what you are committing and when possible, enter the relevant ticket number.
Commits will auto deploy to the server within a few minutes. If you break something, you can roll it back but email the rest of the team to let us know so we can make sure to match our revision to the latest version on the dev server.
To roll back, log into [Spring Loops], choose the project, and then deploy the previous version number.
Remember that other devs are working in SVN too. So, update often, typically before starting a new change set. And commit often. I can help with any merging issues if you need it.
[Info here on how to contact me for an urgent need.]
Further Notes on SVN
The following is just a brief reminder about steps to take to not over write others work.
The Big Picture Provides Intuitive Project Management [Project]
2009-07-24T19:00:00Z
