Let’s start with Project Management.

Bottom line – if you feel straggle with the subject, then it is time to step back and look at “why” and “what” makes it complex.

It usually comes down to complexity in the project definition, uncertainty of what has to be done, idealistic approach, unclear time-line or simply mismanaging.

To succeed, a project should have clearly defined goals, realistic time-line expectations, proper budget and properly allocated resources. When something goes wrong, it usually falls in the above categories.

Let’s consider the following:

• Keep the project simple. If you feel that project really includes several standalone parts, then it is time to negotiate a split, properly presenting advantages to project stakeholders.
• Use tools and practices you are familiar with. Sudden changes in software toolset, ways of getting things done or switching platforms may require double+ time to handle them properly. It’s usually associated with adoption overhead, learning curve, new hardware requirements and other things which are easily not accounted for initially. Yes, there is always a moment when moving from one programming language to another or from one infrastructure model to another is a necessity, but then it should be properly accounted for and handled with more caution.
• Perfection is your enemy. It is a job of the product management to “dream” about the ideal product which will have everything desired. It should not be an ultimate goal for the project itself. The project may be a step to perfection, but not perfection itself. Therefore, when working on the project, look for efficient ways to achieve project goals while staying within associated timeline and budget. If during this time product might be improved then do it, otherwise, do not make it a reason why project would fail.
• “Rubber band” or “Iron hammer”. Even though it feels good to have “iron” sturdy methods, you would find more often that it is flexibility which makes a project succeed. This is the main line behind Agile practices, where sudden changes in requirements, time, resources would not, per se, affect target goal. Yes, some renegotiation/planning might be required in the process, but if all parties do understand the reasons and consequences then the target will be reached without big sacrifices and losses.
• Share the load of knowledge. For you to succeed, everyone on the team should know the project goals, their place in the game and timeline. And you do not achieve that without a significant amount of time allocated to communication – someone has to talk with you, asking questions, sharing ideas, problems and expectations.
• Talk first, do after. Never assume that everyone is with you about everything in the project – some parts could not be communicated properly (even it might be obvious to you), some parts could be viewed and therefore approached differently (every person has own opinion based on his/her prior experience, and it might be different from yours). It might take 5 minutes to make sure that you will get what you expect, instead of fixing something which did not go in the direction you expected it to.
• Document your projects and your talks. This is an integral part of communication; people have better understanding of what has to be done when they write it down. During and at the end it will help to look back and see that what was discussed is now implemented… and it will eventually help you documenting your product features, writing end-user documentation, presenting a new product.
• Let them fly. People, when it comes to creativity have different schedules – some are early birds, others are late night owls. If you are looking for productivity, allow flexibility in the schedule (if business permits). It will pay off and will make the work environment more comfortable. Let people do their job.
• Track the changes. Change management is, in general, a big topic by itself… Let’s just say that you better know what will be changed, when or what has been changed to properly account for possible impact on the product as a whole. If changes are introduced during the time of project implementation, then they should have a clear placement in the “grand scheme of events” with clear understanding of implications.

Conclusion? Be prepared for challenges, be flexible and be open minded.

The post Make the Project Management simple appeared first on Dragonsoft Technology View.

If you do not see or do not know a difference between product and project management, then you probably have a big problem. To manage something efficiently one need to have clear understanding of what exactly is managed and how far area of interest/influence should go. If you are not sure, then it is probably a good idea to think about it.

Knowing who you are is a first step in becoming a good product or project manager. Seeing and understanding other side interest is the second important step. Carrying only about features while disregarding budget limits and delivery schedule does not make you a good product manager. Delivering your projects on time and within the budget would not make you a good project manager, but rather ensuring that code delivered meets all specified requirements. As a result, good product manager should be in a sense be a good project manager. Same is true for any good project manager.

Another thing to remember is that like in any mutual relationship, both parties benefit from each other, rather then trying fight each other.

Can a good Product manager be a good Project manager? Can a good Project manager be a good Product manager?
Yes and No.

There are many situations when person would wear both hats in his/her everyday work, but it does not mean it is a best approach.

By virtue of the definition, even though both have same target goals but do achieve them in different ways.

It is become more and more important for Software companies and their core management to get clear understanding of differences between projects and products, between methods used to manage them and between requirements for Product and Project managers. If such understanding is not reached then business might be set for failure.

All above covers mechanics of the title, but in reality it goes well beyond. Being a manager you are managing the whole process and team is very important part of it. You will succeed only when whole team succeed.

After being involved in many projects and working on many products the following list of rules have proven itself over and over:

• be a professional – manager should understand a business he/she is in. One never become a good in something without throughout understanding of the work performed by others.
• appreciate the work of others and they will appreciate yours
• communicate – listen what people are to say, do not assume you are the ultimate “oracle” and “know-it-all”. There is always something new in every conversation, and it is beneficial for both parties.
• develop the talent in each member of your team – trainings, meetings, study sessions – anything which benefits the overall knowledge, benefits the team productivity
• do not be negative. When there is a negative feelings in the team, it will eventually affect creativity and productivity of the team. Find the source, understand the roots, see what can be done to overcome it and turn to positive side. Do not try to make problem be associated with the person who express it, but rather look for reasons problem exists. Removing person from the team might not solve the problem, but on the contrary make it more wide spread.
• if you made a mistake – admit it – nothing more frustrating for the team as ignorance of its management.
• be honest – trust and not power keeps team strong, making work a comfortable place
• and be yourself– do not “have” different “faces” for your boss and your team, they both deserve the same level of communication.

The post Become a Product Manager appeared first on Dragonsoft Technology View.

In Software Industry is question causes a great deal of confusion:

1. What is the difference between two?
2. When you are writing a software program is it a product or project?
3. When Project became Product?
4. Am I a Product Manager or Project Manager or simply a programmer?

Lets start from the beginning – Product versus Project. When a CEO of your company comes to you with his vision, it is usually translates into number of Projects which will cover several requirements presented. Project will represent “what we need to do” to achieve some goal for the company. It by itself might affect one or many programs. Programs itself might be part of several Products.
Simple analogy Project is a feature(s) you’d like to have, where Product is a reflection/implementation of such projects over the time of development.

Lets look at questions above from this definition and try to provide some answers.

1. I hope we just answered that.
2. As soon as you start to design phase and then write code you are working on the project. When you release your code to be used, it will eventually became a product (or part of it).
3. Therefore, as soon as project requirements and goals are reached and it gets its own life it become a Product. Bear in mind that Project might affect more then one Product.

Question 4 is only to be answered when there is a clear understanding of a terminology used.

Project manager is responsible for the proper delivery of the project – an one-chapter story with well defined goals, scope, associated time-frame, budget and other constrains. There are many things to be covered: resources to be allocated, risks identified and addressed, incomplete requirements clarified and resolved, budget and time line to be set and kept intact. Result of all this effort is to ensure that requirement are implemented and delivered. Once it is delivered and signed off, he will move on with next project. If someone become a guru in this area, then it is a time for PMI certification.

Here are some stats on variances of PMP/PMI Certifications you can obtain to help you with the skills and potentially help your career (source: GreyCampus, the site offers number of online courses and certifications, including PMP training).

Product manager is something different from above. Once the project became product it is a responsibility of the Product manager to remain with it and manage further life of the product. He/she will be focusing on the goal of enhancing a product, bringing it forward in such way that it continues to meet general business requirements and objectives over time. As a result a new projects would be defined and product manager might meet with project managers again, working with them to ensure stability of the product, its health, feature requirements, helping and guiding the team allocated for the new project to accomplish a new goals.

As you can see similarity between two converges into differences in approach. Even though both are applied to the same product, goals associated are different – strict and narrow scope for the features delivered from project manager point and full feature set to meet customers requirements from product manager’s perspective.

Who is higher in chain of command? I think it all boils down to the business model.

If you are a consulting firm, then project is what you do by providing your services.
But if you write and maintain the software then product managers became the ultimate rulers.

The post Product or Project Manager. Decide who you are appeared first on Dragonsoft Technology View.

…hard truth is that most developers don’t think about architecture, but focus more on the latest tools, languages and platforms. They are more concerned about how things are built, versus why they are built, or, more importantly, how software systems work and play well with other systems. That thought pattern needs to come to a quick end

Is it really? Being a developer for over 15 years and being a Product Manager/Architect for almost half of this time, I can see from both sides.

Are developers so reluctant about architecture or they are not allowed to think about it in majority of the cases?

Let’s step back a little, as it was discussed in the “Evolution of the programmer” there are several types of programmers, as there would be a few different one for the Product Managers (we still need to define who is the manager nowa days) and above and “focusing on the architecture” could be off on developer’s level as often as it is on management to be fair.

But when it comes to expressing Developer’s thoughts about an architecture of the software it is really comes to the point when he/she has to decide to do so… and major role here would be played by the management position on what wanted to be heard from lower in chain. It comes to prior experience of communicating such subjects.

Conclusion? Do not blame developers for what they are not. Do you want them participate in thinking about architecture? Invite them! You might be amazed what gold mine of ideas you might discover.

PS. Be ready for the ideas, and keep in mind that they might contradict your genius architecture design. Be open minded.

Copyright © 2026 Dragonsoft Technology View. This Feed is for personal non-commercial use only.

The post Are Developers Hurting SOA? appeared first on Dragonsoft Technology View.