21
1.How to communicate with them so they can be follow my instructions?
The team shouldn't be following your instructions, they should be following a plan that they contributed to and signed off on. As a PM your job isn't to do or manage technical work, it is to make sure that the people who are responsible for the doing and managing are following the plan.
...
14
When I was a new project manager, I had trouble separating my previous role as a developer from my new role as a project manager. What compounded my problem was that it was a gradual move, as the project I worked on started out as just me as a developer, and eventually led to me working as a project manager and leaving the technical details to the team.
...
14
Person-month is politically correct synonym for Man-month.
It's mean amount of work performed by the average worker in one month.
So, if:
project requires 12 persons-months of development time
all team members do only pure development activity (i.e. they are telepaths and they don't need to spend time for communication with each other). [note: this is not ...
10
Great answers before mine!
Let me add this: I see the biggest driver to your schedule woes is feature creep. If you focus on nothing else, focus on this. When features are added like this, you get a new timeline against which to measure your schedule performance. If you are not enforcing an appropriate change process, then being on time is near ...
10
Redefine the Problem
You list several problems that you believe make your projects late. Specifically, you said that:
Deadlines are missed because we're adding many functions in that Web application.
We have people with not-so-good skills for that project.
The people who are freelancers will only have a little time to work.
These may be ...
8
Prioritize, prioritize, prioritize.
One month could be considered a very long time, or a very short time for such a project -- depending on the scope.
So take the scope (ie. "features"), and list items according how their importance.
Start at the beginning. Do one thing at once.
This sounds obvious, but oftentimes developers will start "a little bit of ...
8
Before you go up to management to propose a DMS system, I think you need to understand the problems, and priorities, better. You have already identified lots of disconnects and areas for improvements, and assessed the organization needs a DMS. Actually one of the key issues you mention is the lack of client (prospective and actual) knowledge and information, ...
7
Firstly, you could use different methods/frameworks to run projects. Scrum wouldn't necessarily be the solution here as your prime concern is around the line in responsibilities between these two, both different and both required, roles. As well as getting the right level of communication set up.
I have grasped something from the tone of your question that ...
6
Is the scope of your communication capability just your project team of 16 people? If so, that is a very small, easy plan. Weekly and ad hoc meetings with minutes, risk and issue registers, and a place to store and archive the outputs. Don't over think this as your team is quite small and keep it simple.
However, if your communication requirements extend ...
6
In my professional experience, the single point of contact is a gatekeeper or clearinghouse, rather than a sole resource. This person functions as a spokesmodel for the contract, but may certainly delegate responsibilities or facilitate communications between parties as needed.
This point of contact is the first call you should make with questions, and ...
6
Not to be pedantic, but the correct way to write the term would be person-month, or man-month. The distinction is that person/month implies units of people per month. This is inaccurate.
A person-month is a unit of work that's calculated by multiplying the number of persons by the number of months they work. So a team with three developers working on a task ...
6
The number of communication channels in the Chief-Programmer model is theoretically n-1 because it assumes that everyone communicates with the central chief-programmer role and he delegates work out and that no communication needs to happen between the other roles.
That model does not address real-life complexities and assumes that the chief programmer is ...
5
How to keep a requirements gathering discussion focused on business needs and not technical details?
As Zsolt mentioned, there's no other way to gathering requirements than getting in touch with the business.
As you mentioned that you're a fresh graduated, you may still consider confuse the differences between Tech and Functional Specs. If that's the case, you can take a look at this article from Joel: Painless Functional Specifications - Part 1: Why ...
5
How to keep a requirements gathering discussion focused on business needs and not technical details?
The easiest way is to organise a series of interviews with your clients. During the first session, you talk about the product, create some sketches either on paper or on the whiteboard about how the product should work (it may be a good idea to record the session with the permission of the clients). After that, you go back to the team, and together you ...
5
It doesn't mean tools are to be avoided. The actual text of the Agile Manifesto, from which "interactions over processes and tools" is taken, says:
That is, while there is value in the items on the right, we value the items on the left more.
So we value individuals and their interactions more than we value processes and tools, but we still find value in ...
5
There is nothing wrong with having several people from the project team contacting the client. As you already pointed out, some people are naturally more appropriate. If you developers are interfacing with the client's systems and there is a specific coding problem, then the dev might need to talk to a client dev contact.
Normally, the client will have ...
5
It is highly unlikely that your "single point of contact" (SPC) is the only stakeholder [person with an interest in the outcome your project]. Although contracts will identify a SPC such as a contracting officer or contracting officer's technical representative, this responsibility is a contractual requirement to ensure that contracts are not modified by ...
5
Pankaj Jalote in the book "An Integrated Approach to Software Engineering" describes three types of team structures:
Ego-less team (aka democratic team).
Chief-programmer team.
Controlled decentralized team.
Ego-less team have no leader. All decisions in it are making through discussion and with consensus.
Every member of democratic team have ...
5
Two key expectations from a PM are:
Assess, track and report Risk
Manage Stakeholder's expectations
You are doing all the risk management, and it seems the second part could be improved. So, you could take some actions, such as
Consider and cost, on your original plan, the risk of going 50% beyond schedule. With this, you'll be agreeing upfront the ...
4
From my experience on the "work" side of the equation (ie, implementation, not management), the most common format I have used and been asked to use is this:
Subject - [project] [time] status [date] {detail (could be a subproject)}
Greeting
Status
bulleted list of accomplishments of the day
Pending
bulleted list of issues that are upcoming or may ...
4
From my experience, I would say the problem here is "leadership". I am just taking couple of points from your statement.
Team not successful in convincing clients when requirement creeps
Team do not give importance to communication skills and they believe it is not a part of their job
These are things that should be driven by a strong leader. The leader ...
4
I'm going to read between lines a bit here, but I think the issue that management has is not explicitly that the mitigation strategy is too reactive- mitigation, almost by definition, has to be reactive. I think the issue is that the way you are handling the project is demonstrating that you don't really know what the budget or timescale should be and that ...
3
TL;DR
The legal questions are really just a subset of the premise that this is fundamentally a business decision, albeit a highly political one. Determining whether or not to kill a project, and who should be assigned to a trouibled or failed project, is primarily a business decision with potential consequences (good or bad) to all parties regardless of the ...
3
How to keep a requirements gathering discussion focused on business needs and not technical details?
"So, what is the best way to collect business requirements?"
As others have said, working directly with business, managers and staff (SMEs), is the best way. Given that, you can't just ask what they want; that is an open-ended question. Creating a prototype is a good way to give feedback on the requirements, but it is much better if you have a grasp of the ...
3
This should be documented in the communications plan. There are almost as many answers to your question as there are combinations of clients and providers, which is why each project should have a communications plan that summarizes who talks to whom about what.
In your shoes, I'd create a template communications plan for the company, and then validate key ...
3
If you are talking about how to manage effective meetings, your best bet is to call out when what the two managers are contributing isn't adding value. You can do this by politely taking the first opportunity (when they pause to catch their breath?) to ask them to take their discussion offline and come back to the next meeting with a recommendation. ...
3
Is it wise to send email meeting invites in advance for each of these 3 meetings?
Yes. It allows the attendees to plan their own diaries and helps to ensure they will be available at the time of the meetings, which is good for your projects
Should we include this in our Communications Management plan?
That depends on practise at your organisation. Some ...
3
I understand that the situation are:
You are a technical lead (TL),
You report to a PM that has no or almost no domain knowledge, technical knowledge.
The PM does not understand you.
"A non-technical PM cannot identify certain dependencies because they have no idea that they exist.": He doesn't have to. I think it is your main responsibility to explain the ...
3
To be blatantly honest, if your project has a non-technical project manager who is not very strong on the business logic or functional aspects of the project and is also involved with other projects, his involvement in the project should be no larger than that of managerial tasks – which is a nicer way of saying – "Getting the crap out of your team’s way and ...
3
TL;DR
Should I include the developers in these emails or not?
Increased direct communications, if done effectively, can improve the viability of a project. However, there are often pros and cons that must be considered. A lot depends on your project management framework, your project communications plan, and on the type of relationship you have with your ...
Only top voted, non community-wiki answers of a minimum length are eligible
