Tag Archives: project manager

Recruitment and social networks

Posted on by
Reply

Two reports, published by Jobvite, analyze the relationship between social media and recruitment, with special regards to the American job market.

They are 33 essential recruiting stats and Job Seeker Social Survey 2011. In short:

  • 55% of the companies surveyed plan to invest more resources in the next year for recruiting with social networks
  • more than 80% of companies use LinkedIn, but just 30% of job seekers is in LinkedIn
  • 89% of the U.S. companies surveyed indicated their willingness to use social networking as a tool for recruiting
  • LinkedIn is confirmed, with 73% of usage, the largest social network in terms of recruitment, followed by Facebook (20%) and Twitter (7%)
  • 2/3 of the companies surveyed have hired thanks to social networks

On the same topic there are two interesting infographics published by Mashable, the first with suggestions on how to protect and improve the professional online presence, the second presenting the results of a survey based on recruiters and the relationship with social networks.

And, speaking of statistics and surveys, I remind you that also this year A List Apart published one for anyone who works with the web. Starting from the results of a previews survey, in 2008 I tried to give an interpretation to better understand the role of the web project manager.

Learning from one’s mistakes

Posted on by
2

Some projects fail. Once I received this email from one of our clients:

Good morning [account manager] and Antonio,

we want to express our disappointment regarding your behavior and the work done.

We believe that the many requests and modifications we are asking you are a direct consequence of your work. We refer, in particular, to the fact that we asked you a_b_c while you proposed us d_e_f. You can agree with us that in this way our objectives were not met. We are now in the process of putting online a product that is quite different from the one that we wanted.

Our criticism is based on the lack of suggestions and ideas from your side – experts in this field – and on your attitude of mere executors.

Shocking, isn’t it?

A message with such a tone isn’t a bolt from the blue, but rather a direct consequence of an email sent by us in which, rudely, we ask the client to allow us to close the several activities in progress and to stop adding new ones every couple of days. Obviously this is not the right approach. It’s just the last in a series of errors that, from both parties, characterized the whole project.

Before analyzing what has gone wrong it’s important to put the project in its context:

  • the first meetings with the client were held  a year and a half before this email;
  • the project covered the creation of a web site with features such as booking, searching, non-standard e-commerce procedures, and with a link to an external and proprietary information systems for price lists and address books;
  • the site was meant to substitute the previous version, built by our agency;
  • after the requirements analysis phase and several brainstorming sessions, we presented a working prototype containing the main features of the project.  The client was given the opportunity to experiment with the prototype for some weeks;
  • the total effort estimate was 350 man-hours.

The client, even if it doesn’t seem so by reading the email, has been involved in every step of the project

  • the gathering of useful elements for the project were based on a series of meeting where the client set his expectations;
  • we developed a working prototype of the application, sharing every detail with the client;
  • we chose to split the project in about 5 parts to shorten the deployment and let the client test the various functionalities

These seems to be solid basis for building a valued product. The email we received, however, is not on the same wave lenght: our client is unsatisfied, convinced this is not the product he wanted and expresses doubts regarding our expertise. How can this be possible?

If we take a deeper look at what happened, however, we can easily notice that many mistakes were made, on both parts. Here’s a list with the most important ones:

  • Mistake #1: you need a brand new site – It all started when the client expressed some perplexity regarding the site currently online. The site was fine after all, but there were some bugs (above all there were usability problems, especially of interface coherence). At this point the client is persuaded to redesign the whole site and he is promised a better, more usable, faster one. Maybe it was not necessary a complete redesign.
  • Mistake #2: it will cost you 100. No 300. Let’s make a deal: 200 – Without any analysis a first estimate sent to the client is far from the truth. Having developed the previous version doesn’t necessary mean that estimation for the redesign is easier. The real estimate is three times the first one, the client is astonished and we agree on a price that disappoints both parts.
  • Mistake #3: a phantom, not a client – We did not stress enough that we needed their help and approval throughout the project lifecycle. Approving a prototype meant to the client that the development phase was just a boring activity with no decisions to be taken on their side. We did, to be honest, included an estimation of their effort in the project documentation, but it was not enough. We waited weeks for an answer, sometimes.
  • Mistake #4: client contacts not motivated – To succeed, everyone involved in a project has to master communication skills, especially the project manager and the people on the client side that relate with her. That didn’t happen. The project was assigned to a freelance that didn’t succeed in answering doubts and questions and evaluate proposals. When you are in such a situation raise your hand before it’s too late.
  • Mistake #5: software is intangible so you can change it till the last minute – Even if it’s possibile to evaluate a change in the specifications, this has to be seen as an execption, and not a rule. The project seemed ready to be put online, but not on the client’s mind.
  • Mistake #6: the site doesn’t do what i want – The site doesn’t have to behave as you want, but as your user want.

PMBOK and agile development

Posted on by
Reply

A Guide to the Project Management Body of Knowledge (PMBOK) is considered the bible of project management. Bible in that it deals with every facet of project management by means of 5 process groups (initiating, planning, executing, monitoring and controlling, closing). Bible also for its size, more than 400 pages packed with concepts that often scare who is studying to become a Project Management Professional.

Thanks to this reputation, concepts expressed in the PMBOK could seem far from the agile development methodology and some weeks ago I expressed my opinions regarding this topic in the Web Project Management FAQ.

And now Forrester publishes on its site an interesting (but not free) report, The PMBOK and agile: friends or foes?, that deepens these arguments.

Starting from the differences between PMBOK and agile development, the authors soon highlight several points of contact between these 2 approaches. But it’s the last part of the report, where they state that it’s possible to combine the strengths of both to optimize outcomes, the more interesting.

In particular, an agile developer can find in the PMBOK:

  • a help to clearly define project initiation and closeure;
  • a guide to effectively communicate with all the stakeholders;
  • clear directives for risk management.

Conversely, an agile methology can help traditional project managers in:

  • defining roles and responsibilities across teams, giving individuals the opportunity to learn from each others and to plan collectively;
  • encouraging teams to focus on detailed planning of smaller blocks and using that knowlegde to influence future planning;
  • building stronger relationships with customers;
  • writing the “right” amount of documentation.

Introduction to web project management

Posted on by
12

Update: I recently wrote the Web Project Management FAQs

If you look at my profile you’ll see that I work as a web project manager. But what does a web project manager do and, consequently, what is web project management?

A web project manager is a professional that deals with the management and coordination of a web project (site or application) from its inception to the delivery (and more, if a maintenance phase has to be considered). The web project manager is an all-accomplished figure as he gets in contact with the client, with the salespeople, with designers, with developers and with systems analysts; with – in other words – everyone involved in the project.

Compared to a project manager in the traditional software field, the web project manager usually works on pathways that have yet to be explored. Constant innovation, heterogeneous working groups, agile development methodologies are all variables that deeply influence his working behaviour.

It’s quite difficult to define exactly the skills of a “good” web project manager, but we can try to list them. A web project manager

  • is able to evaluate a project in terms of cost (infrastructure, people, content, maintenance), time (needed to design and develop the application and delivery date), quality (measuring it with quantitative metrics)
  • interact with the client. At the beginning of the project meetings are held with both the web project manager and a salesperson; subsequent meetings are managed solely by the web project manager together with the client. The web project manager is often the client’s only referent; that means he is also the only one responsible for delays/bugs/misunderstandings related to the project
  • works with a group whose members own very heterogeneous skills
  • masters communication skills: face-to-face, in a meeting, on paper. A web project manager can write documentation fluently, especially the requirements document and the project specifications. Sometimes a web project manager designs prototypes and wireframes
  • chooses the most appropriate professional figures for a particular project
  • is able to plan his team’s timeline even when there are concurrent projects in development
  • doesn’t just define costs and timings on his own, but knows when and what to ask to his team in order to obtain a detailed and shared forecast. He’s not a one man band.
  • he believes in group spirit, and cultivate it
  • promotes and rewards everyone’s success. The project manager suggests improvements in one’s professional skills when he thinks it’s time for something new and eventually is able to evaluate the achievement of agreed objectives
  • is conscious that problems can’t be avoided, but knows how to anticipate them. He is able to recognize them in advance, so they can be addressed before they turn into emergencies
  • defines how much space there is for innovation in a new project and when, instead is better to reuse consolidated solutions
  • finds and works with teams and freelances in outsourcing when internal resources have been already allocated (or are not enough skilled for the particular task)
  • knows how to design and develop most of the project on his own, even if with poorer results compared to his team. This allows him to estimate projects with good approximation and to understand his team’s problems and difficulties
  • understands when to accept compromises – budget constraints not always allow to build an excellent product

When the web project manager improves these skills, the quality of his work improves too. Using delegation in the right terms, for example, can lead to the development of new skills inside the team and can add more time to other opportunities for the web project manager himself.