Project Management 101: The Importance Of Your Team |
|
Written by Michael Ferrantino
|
|
Sunday, 08 June 2008 00:00 |
|
I decided to write this blog because 2 project managers at a publicly traded company recently asked me a hypothetical question: "what if the engineers tell you that a
component that needs to be developed (using PHP) is going to take 3 weeks to complete - but you need it in 1 week?"
Before I address the above question, I think it's worth mentioning that web development teams are most commonly comprised of the following four groups:
- Stakeholders (owners, executives, marketing, editors, etc.)
- Tech (web developers, integrators, database engineers, IT specialists, etc.)
- Designers (graphic and UI designers)
- Project Manager (can be more than one, in hierarchical form)
The normal course of a project almost always begins with a directive that comes from a project's stakeholders (at large companies, it might be a visionary
executive or at the grassroots level, an entrepreneur). If they're not already, it's important for marketing to be involved on a foundational level, so that advertising
and pr campaigns can be planned well in advance.
With that said, it's now left up to the project manager to assemble the tech and design teams, create a schedule, identify dependencies, budget, and at times,
function as gatekeeper, mediator, negotiator and peace keeper. In short, the project manager is the kingpin from which a project's success hinges.
Getting back to our hypothetical question. My first thought was that the team at the company in question was probably in trouble, most likely due to missed
deadlines or unrealistic goals that had been imposed upon the engineering team in the past. The company thought that the solution to the problem would be to hire project
managers who were highly skilled in various programming languages. However, this is a mistake due to confusion or lack of understanding between a tech lead and a project manager.
A project manager should have an understanding of a project's related programming languages, especially in terms of their respective limitations and current best uses.
However, it is unprecedented for a project manager to be required to perform programming work, while simultaneously managing a project's development and coordinating the efforts
of the various groups listed above.
My response to the question was that I would rely on input from my engineering team. It was at that point, I noticed the two gentlemen's eyes glaze over and ears fill
with wax. What they also didn't know (and quite possibly might have been a foreign concept) was that my response assumed that
trust existed between myself and the engineering team (and for that matter, between all the teams on the project).
The answer here was so simple, that it was easy to miss!
Two things come to mind: Dilbert and Occam's Razor,
which states that, "All things being equal, the simplest solution is best."
|
|
Project Management 101: Understanding Web Project Management |
|
Written by Michael Ferrantino
|
|
Thursday, 05 June 2008 00:00 |
At Blue Lab, we've successfully launched, maintained and turned-around hundreds of websites from eCommerce to informational. Since the mid 1990's, we have watched web technology grow and change --and we've learned a lot about what's commonly referred to as, "best practices" for web-development project management.
In the early days, I studied the project management body of knowledge (PMBOK) - and later the Rational Unified Process (RUP), where iterative development was born into and/or out of software development -and later web software development. All this was to unhinge designers and engineers from the classic waterfall approach resulting in bringing a product to market (online) as soon as possible (once a pre-determined minimum feature set was integrated).
Excellent Project Management is built upon two documents:
- The Project Plan, which includes the fundamentals: the team, schedule, milestones and budget.
- The Feature Specification Document: the blue print for development.
The industry standard software for creating a Project Plan is Microsoft Project. However, I also have experience using a secondary tool, Alexsys Team 2 - particularly for task management.
The Feature Specification Document is primarily authored by the project manager with contributions from the project's engineers, developers and designers. The beginnings of the document almost always begin with a project's business requirements and long-term goals. The Feature Specification Document is known as a "living document," which means that as a project progresses through the basic stages of development (requirements, team building, scheduling, development, integration, QA and launch), the document grows as in a journalistic fashion.
In lay-terms, the Feature Specification Document is the blue print from which engineers, developers and designers build the system. I should mention here that the Feature Specification Document is also the road map for building the data model and database (where applicable).
The Feature Specification Document is what future development teams and/or the webmaster will use as a reference.
The three most common reasons (or excuses) for not creating documentation are: - It's costs to much.
- We need to just get the project launched now - we'll document later.
- Just let the engineers and developers build it (we don't need much project management or documentation - after all, that Tom guy who built MySpace supposedly did it while sitting on the beach).
When a project is not documented, the end result invariable looks sloppy - and in the long run, development is done twice. There's a saying, "if you buy cheap, you'll have to buy twice."
|
SEO: What's Working; What's Not |
|
Written by Michael Ferrantino
|
|
Wednesday, 04 June 2008 00:00 |
|
I recently read a posting, where the poster was looking for an SEO specialist who could work with the metadata for a specific product / asset. The reason the ad struck me, is that they were looking for a "specialist" - but at the same time dictating the best methodology for accomplishing their SEO needs. If you're working in corporate America in technology, you'll understand this posting to be a part of daily life - a quite Dilbert-esque daily life.
Let's get some facts straight about SEO. Because best practices are changing daily, I suggest:
- Read up on the subject -daily
- View SEO in the proper perspective
- Assemble a small SEO team and meet at least once a week (this meeting should take 15 minutes or less)
- Monitor performance -daily
Viewing SEO in the proper perspective means that SEO is not a stand alone effort. Like all marketing efforts, it should be part of a larger arsenal that includes, AdWords, viral efforts (blogging), advertising and PR. We've worked with clients that ignore PR but were heavy into advertising and vice versa. Without getting into the ongoing debate about PR vs. Advertising, the correct methodology is coordination and balance between all efforts. When your campaigns are running, your website needs to match what's in those campaigns.
Your SEO team should include a webmaster and marketing person (if possible, junior-level will suffice). What should be discussed during the weekly meeting is traffic analysis and if applicable - sales and competition.
At the beginning of this blog I talked about metadata. The current problem with metadata is that search engines are more commonly crawling what's on the pages of a site -rather than what's in the metadata. For example, our SpellBy.com site has a visually weighted home page. Given this information - we now have to switch our strategy to include more product descriptions, which is something we were always reluctant to do because we know that most consumer purchases are based on the strength of the product images. Here, SEO changes what was once a best practice for selling product --not because it doesn't work anymore once a customer gets to your page - but because of the necessity of getting the customer to your page in the first place.
|
Thoughts on Enforcing Your Patent |
|
Written by Michael Ferrantino
|
|
Tuesday, 03 June 2008 00:00 |
You've come up with a great idea, taken the time to develop and refine it - and even spent the money to file for a patent. You've even successfully brought your product to market. Now you notice that other "similar" products are appearing on the market. What do you do? You enforce your patent, period.
There really is no daisy-petal game of, "to sue or not to sue." Thinking, talking and writing about it regretfully, is an even further waste of time. If you don't take the necessary action to enforce your patent - you're derelict in your responsibility to your idea, your company, employees, family and most of all - to yourself. Why am I taking such a hard line here? I watched a former client's business deteriorate year after year, as the patent was infringed upon. This particular client, like many people, instead - chose to get bogged down in the details of their patent - and used that as an excuse not to enforce it, even when expert legal council advised otherwise. The bottom line is - it's well worth the cost to enforce your patent - and I dare say, it's somewhat of a civic duty. In business, you pick and choose your battles - and sweating the small stuff in lieu of something as big as your patent, will only keep you small.
|
|
|
|
|
|
|
Page 4 of 5 |
Tech Blog